Vincenzo Gianferrari Pini wrote:
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.
Imho this is a point release definition: what I would expect in a 2.3.0
to 2.3.1 upgrade.
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.
Yes, but we already used a different scheme for 2.1, 2.2 and 2.3.. so
why change it for 2.4?
If you really want to follow this numbering we should renumber the
current 2.3.0rc3 to 3.0.0 and not 2.3 and start working on 4.0.0, but as
we have 3 numbers, why should we only use the first?
Anyway, I always said that I don't care about the number while
discussing, I just care about what we release and when. So we can even
talk about "the next release" and skip the number if this helps (we'll
vote the number just before the release).
2.x releases have been storage compatible in past, so I think we can
safely put in the 2.x scheme every future storage compatible release and
keep 3.0 for bigger steps, but mine is only a +1 vs +0, no vetoes about
this meaningless thing: we need code to make releases, not numbers.
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.
If we take everything we have in trunk now and compare with 2.3 I think
that fastfail is one of the few things that cannot be backported as is.
As I already wrote we have uncomplete code both in trunk and in an
unfinished handlerv2 branch, so it's unfair (imo) to think that merging
fastfail to 2.3 is less work or it is safer than releasing current trunk.
Furthermore what you define "useful" is not what others may define
"useful", so don't be so blind: I did a lot of changes for 2.3 that were
not useful for 2.3 itself but now are the basis for the new
developments. If I didn't include them in 2.3 we now would have much
more code to test for the next release.
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.
If this is your conditions then I say let's skip 2.4 (we can't afford
it) and work on 3.0 (see my 2.4 proposal and call it 3.0).
I don't agree with this change in the numbering (why shouldn't we use
the third number ???) but I really don't care now.. We can vote the
preferred number the day that we'll have to release.
Furthermore I want to let you know that the new fastfail stuff need
changes to configuration files and would no allow conditions (ii) and
(iv), so using your numbering scheme would not be suitable for 2.4.
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.
This matches what Norman and me said, but you simply want to call the
next release 3.0 and not 2.4.
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.
As I already said I won't work on this 2 months timeframe release, but I
won't be against it if you are able to work on it: I bet that in 2
months we won't even have the first RC in your roadmap, but I would be
happy to be wrong about this.
I only care that this will not become a delaying issue for the release I
want to work on (call it 2.4, 2.5, 3.0, TNG or reloaded, not important now).
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.
Well, in the last year we at least produced a release, the year before
this one nothing happened.
As a james user I prefer to have a release, than nothing.
I don't expect our small developers community to be able to follow
strict roadmaps and that's why I proposed a time based roadmap. We had a
2 years release cycle for the 2.2=>2.3 step (i've been involved only in
the second year). It took one year from 2.1.3 to 2.2. So I would be
happy enough if we can start producing a new release every six months:
this is four times better than with 2.3 and 2 times better than 2.2.
The only release I expect to come out faster is an optional bugfixing
2.3.1 release that should be prepared and released *before* branching
the trunk for the following release (so we follow the rule to have only
trunk and another active branch).
I hope all this makes sense :-) .
Vincenzo
I see that we have different ideas on the roadmap (or only on the
numebers?), I hope we can at least agree on the 2 working groups so that
we don't have to loose time discussing a roadmap that maybe no one will
ever be able to implement.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
