On 9/14/06, Norman Maurer <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
