james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: JAMES v2.4 Road Map
Date Fri, 15 Sep 2006 10:26:30 GMT
On 9/14/06, Norman Maurer <nm@byteaction.de> wrote:
> Vincenzo Gianferrari Pini schrieb:
> > I think that we have different goals and views about what is a minor
> > release, and how it should be reflected in the naming (numbering) scheme.
> >
> > For me (and as I understand also for Noel) a James x.(y+1) release
> > should be a release that (i) comes out after no more than 2-3 months
> > after an x.y release, and (ii) that can be put into production just
> > replacing the james.sar file and maybe adding/replacing/deleting some
> > lib jars, (iii) keeping storage compatibility, (iv) without any need
> > to change either config.xml, assembly.xml etc. and (v) without any
> > database schema changes (btw, IMHO point (iv) is very important).
> > James should be able to restart without problems, and changes to the
> > configuration files should be needed only to activate new
> > functionalities, and such functionalities should have been well tested
> > and "reasonably safe" and useful.
> > I know that it was not this way in the past, but I feel it should have
> > been, and should be from now on.
> >
> > Based on this "definition", 2.3 should have been 3.0 (and what we are
> > calling 3.0 should be 4.0, but let's forget that :-) ). This
> > "numbering scheme discussion" obviously is useful only to better
> > understand each other, also in the future.
> >
> > So this is how I think 2.4 should be: useful things that deserve and
> > *can* be added to 2.3 in a short time frame, without too much work:
> > very first among others the new fastfail (*if* the "without too much
> > work"  applies). "Time driven instead of feature driven" for minor
> > releases.
> >
> > Now, how to do that? I think that the only way is through Noel's
> > approach: carefully evolve 2.3 to 2.4, adding at least (at most?) the
> > new fastfail, plus other carefully chosen things. The code from trunk
> > currently  would not allow conditions (i), (ii) and (iv) above, and
> > should be used to become 3.0 following Stefano's and Norman's
> > suggested roadmap. And after 3.0, any 3.x probably should evolve from
> > 3.0, and a 4.0  would come out from trunk.

> Who will do this merge and test it ? I don't think it will be more
> stable then the code in trunk.  For me that make no sense.. Then we have
> to maintain 3 trees. We are to few developer for that.

I share Norman's objections. Maintaining 3 trees will not help us
progressing, it will only help stalling the project.

> For me its:
> 2.3.x = bugfixes
> 2.4 = 2.3.x + new features ( compatible)
> 3.0 = incompatible changes

addition: 3.0 = incompatible changes, big new features

+1, thats absolutely my take, and my understanding about what is
common sense in the industry
And I don't think its only a number. It is a means of communication to
the user base.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message