Stefano Bagnara wrote:
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.
Well, I consider a "point release" a simple "bug fixing release, with no
new features", as a 2.3.1 would be (possibly not needed).
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?
Because IMHO it was wrong :-) .
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?
See above.
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.
Not only storage compatible, but also configuration compatible etc.
About numbering, it is like naming: helps in stating things.
And please breathe a second and take it easy before ironizing and
telling other people that they say meaningless things etc. You won't
convince anybody this way, you will only put them off.
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.
I don't say that it can be backported as is. My hope (and I know that I
may be wrong) is that it can be backported with some work. And releasing
current trunk means releasing the *whole* 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.
I'm saying *functionally* "useful" from a James user point of view, not
useful for *new development*. But in general you are right.
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.
The point is timing: I would like to have a sound release come out in
2-3 months, while working in parallel on a major one expected to come
out in a longer time frame. And the numbering scheme just expresses that.
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.
My point is (without integralism) to be able to get 2.4, and have my
production system run doing the same things as before with no or at
least little effort (no or very little changes to configuration) and
then, when I'm confortable, start exploiting the new features by
changing the configuration files. By little effort I mean also the
ability to easily rollback if weird things happen. And you know that
going from 2.2 to 2.3 was not simple at all!
*If* those things turn out to be impossible, then obviously we will
follow your and Norman's roadmap :-) . But *if* it is feasible, as also
Noel thinks, this is my choice.
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.
No, I'm talking about timeframe (2-3 months). If I have to wait 6+
months for 2.4 and slightly more for 3.0, it would be stupid to work on 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).
I agree. I see work always being done on trunk, and some backporting to
a 2.4 branch.
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.
Stefano, since you came in you did a tremendous and enormous work, and
we all did appreciate it a lot, and we know that a very large part of
2.3 is your merit. But one year ago (after a regrettable delay) we were
going to come out with a ("smaller") 2.3, that we were then unable to
finalize also because of your "vulcanic" :-) activity. And I bet that
if a few months ago we didn't decide to converge after some arguments,
2.3 would still be "on the clouds".
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).
You see that your numbering scheme uses the third digit for bugfixing
releases ;-) .
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.
Discussing is not losing time. I try to convince you and you try to
convince me. You must convince me (and I'm quite open to it) that what
my roadmap is not feasible ("no one will ever be able to implement") or
that yours is "better", whatever it means.
Stefano
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
