Jim Hurley wrote:
Hi all-
Just wanted to propose a short term conceptual plan
forward for Apache River, and see if we're in sync.
Thanks for starting this Jim. Below some of my initial thoughts on your
ideas.
Once we get the source accepted and contributed
to the project (hopefully this week!)... I'd like to propose
that we immediately start working on a release (v0.1). This will
not only help us understand the paces of getting a release
out through Apache, but also provide a release to the Community
from Apache. To focus on getting a release out, the initial work
would be targeted at integration stuff (for example, getting Service UI
integrated) and some documentation rather than on very many
bug fixes or rfes.
Once we accomplish that, we can turn our focus towards another
near term release (v0.2) which could include additional bug fixes
and smaller rfes as well as any cleanup we learn from getting
the v0.1 release out. This would not only provide an added value
release out to the Community, but also give us further experience
and additional momentum of an active project moving forward.
I find v0.1 not ambitious enough. I think it is important to do some
bug-fixes and RFEs that have been completed and lingering around for a
very long time in some peoples workspaces. Just to release so most
people can sit on the sideline watching v0.1 being released is not that
interesting to me (I also want to get rid of a lot of fixes and small
RFEs I've been carrying for too long). Therefore I'm inclined to merge
the goals for v0.1 and v0.2 as most of it likely represents completed
work. Based on what is in Bugtraq, has been added to River and is
completed in the Sun internal version control system we can make a
selection of what to put into that first release. Whether there is still
a need for a release between the first release and the 'meat to it'
release I find hard to say at this point.
With regard to the version numbering you used. The version numbering
between the Jini Specifications and the JTSK has been correlated to an
unhealthy degree IMHO and I think starting from zero isn't the best we
can do as likely the first releases will be something that resembles the
JTSK from Apache instead of from Sun. As long as we don't have a clear
(as perceived by our audience) separation between the specs and the
implementation/starter kit I would suggest starting at 2.2.
The more 'meat to it' specification release could become 3.0 and
whatever products/deliverables we end up with could start using a
version number that does justice to it.
At that point, I think we'd be seasoned enough to focus on a
release with some 'meat to it' ;-) (some of the more major bug
fixes/rfes that have been discussed).
Agreed.
Running in parallel to this development focus, I think there
should be some longer range project discussions (what kind
of releases do we eventually want to do in the project, what
are we trying to accomplish (iterating on the core infrastructure
or branching out into other areas), etc).
Agreed.
ps. On a specific item - not sure where a package name
(to org.apache) change would fit in this proposal. Maybe
release v0.2 or after?
As far as I'm concerned after v0.2. This won't be a trivial change and
probably something we should do while we try to get the question
answered about maintaining compatibility, not something for the v0.2 to
be tackled I guess. Or in other word, if we pursue a change with major
impact I think it is also the best opportunity to make some changes that
could lead to (minor) incompatibility and that will require a
significant window in which to sort that out.
Another thing that should be discussed is the minimum J2SE version we
are going to conform us to for these initial releases. For v0.1/0.2 I
would say we should stick to J2SE 1.4 and for the 'meat to it' release
we should start the discussion about moving to 5.0.
--
Mark
