river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Calum Shaw-Mackay" <calum.shawmac...@gmail.com>
Subject Re: Short term plan forward... (proposal)
Date Mon, 21 May 2007 23:03:03 GMT
Just as a further note for discussion, I believe we should be engaging
the community now about the next iteration of the specs (i.e. things
like Executor extension for Javaspaces, et al, XA transaction manager,
etc) and what wants to be seen in the next iteration of the core
services (Nested Transaction Manager implementation for example), so
that from that area, things can be seen to be progressing.

Just a thought


On 21/05/07, Mark Brouwer <mark.brouwer@cheiron.org> wrote:
> 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

View raw message