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.
So, if the new fastfail is not mature enough, an effort should be put on
it to become so in the 2-3 months timeframe. If not possible (but I
don't think so), the remaining things may not be enough to justify a 2.4
(unless we have bugs in 2.3 to solve that would force us to build a
2.3.1: ------ 2.4 = 2.3 + bug fixes + new features ------), and we would
have to wait for a 3.0 coming out of trunk when we decide to branch it.
Who would do this 2.4 work? We know that *currently* the most active
committers are Stefano, Norman and (slightly less Noel), followed by
myself and Bernd that are both more oriented to contributions in
specific areas (btw more "release independent"). So Noel and Norman
could hopefully concentrate on fastfail and related functionalities, I
would work on Bayesian, Crypto (+something else that may come out) , and
Bernd on whatever he feels useful, appropriate and possible. And Stefano
can concentrate on more long term things for 3.0 and jump into 2.4 when
possible.
To "wrap up", a final consideration: as a James user, I prefer to have
*soon* a *few* new and "safe" functionalities rather than to wait a long
time for a lot of new functionalities. But in the long term I want James
to evolve ambitiously.
I hope all this makes sense :-) .
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
