james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: Version numbers (Was: LONG JAMES v2.4 Road Map)
Date Fri, 15 Sep 2006 20:52:18 GMT
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 <apache@bago.org> 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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message