Stefano, Sorry, cannot parse this. You lost me way before you said that -1 should not be the next version number for James. I feel stupid. You are using too much words for me to cope with. Do you have 3 or 4 simple words summarizing your ideas?
Are you saying that, the higher the next version number will be, the more substantial changes can be made? - That, I would agree upon. Bernd On 9/15/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Jürgen Hoffmann wrote: >> I still don't know what Vincenzo and Noel want to do with the >> "next-minor" release so I'm not able to vote now the number of their >> release. We also don't have a string roadmap for "next-major" release >> (6 months) and I would be more inclined in using 2.x if we don't add >> some more major change in current trunk, but I won't be against 3.0 or >> any other number. I simply say that I'm fine with "next-minor" and >> "next-major" and we can define the number as the release content is >> more concrete. I think that in 3 months we'll be able to evaluate a >> number for next-major, I can't say anything about next-minor until I >> say the list of things that they want to backport (it seems to me that >> the roadmap for this next-minor is not so defined yet) > Great. So let us keep it in that way. You are fine with > 3.0 = Trunk > 2.3 = Release Branch with possible bugfix sub releases > 2.4 = Features that went into 3.0 which would be great to have within > the 2.3 application layout (This Integration Effort is do be done by the > 2.4 maintainers) I think the main "problem" in this discussion is that I believe that changes that are in trunk now and that I would like to put in the 6 months release (next-major) are on the same line and on the same layout of 2.3 and they would be part of 2.3 if we didn't branch before. In fact the only common thing between 2.2 and 2.3 is that it is storage compatible and it didn't changed too much the mailets api (but they changed, and furthermore we changed the WHOLE avalon references from components to services). From 2.3 to trunk and to the other features we listed as possible candidates for inclusion there is nothing different from this: we'll keep it storage compatible. (I avoided committing storage incompatible changes because I thought to this "personal" roadmap few months ago). So if I was the only one to choose names I would use the 2.4 for the "next-minor" and 2.5 for what we defined "next-major" and delay major changes in the architecture for 3.0 (dsn support, container changes, repository changes) and I would use 2.4 for "next-major" in the case there was no "next-minor" release. I thought this (my idea) was clear enough, but I prefer to be clear so I tried to explain it one more time. I think that the numbers are appropriate from a developer perspective: imho the first number change has to be related to total rewrites or to major architectural changes included. The second number is changed when new features are included, the third for minor releases (tipically bug fixes or really small changes). I also understand the marketing importance of "big" version numbers, as M$ teach us, but I don't like James XP or James 2006 ;-) and that's why I alsways said that I prefer 2.3 for the current branch and not 3.0 and why I think the next should be consistent with that schema. And about consistency if I knew that the next-major will be an increment in the first number I would probably have preferred 3.0 for the current 2.3.0 and 4.0 for the next (this reflect much better what we changed). I hope I have explained enough the "why" behind my ideas and I don't think I need to convince anyone that my idea is better than another. In past PMC decided to give me the rights to vote (and I hope I deserved it), so I will simply vote my preference and be sure I won't use a -1 for the version number. The only thing I care is to be able to work on my goals when I have the right mental state to do a good job: if we call next-major 3.0 I simply have more freedom on changes than what I would have if the branch is called 2.5 ;-) so this is enough to be happy even with a bigger number. Furthermore if we use a major number we can also deprecate things and remove some old deprecated code. So I think we should just wait for Noel, Vincenzo and anyone else that is willing to work for the "next-minor" release to prepare a list or things to be included and we can decide what the version will be (and I believe that if such release will be prepared we'll probably agree on the "2.4 branch"/2.4.0 release). About next-major we have 2-3 months before branching and I would like to keep storage compatibility anyway until that day (if possible), so we have a lot of weeks before we'll have to "svn copy trunk branches/vX.X" ! Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
