Version numbers (Was: LONG JAMES v2.4 Road Map)

[Stefano Bagnara <ap...@bago.org>]

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

Re: Version numbers (Was: LONG JAMES v2.4 Road Map)

[Bernd Fondermann <be...@googlemail.com>]

On 9/16/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> > 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.
>
> More easy: Let's do the changes first, we'll define the numbers later.
>

+1

(Wow, it is as easy as that?)

  Bernd

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

Re: Version numbers (Was: LONG JAMES v2.4 Road Map)

[Stefano Bagnara <ap...@bago.org>]

Bernd Fondermann wrote:
> 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.

More easy: Let's do the changes first, we'll define the numbers later.

Stefano


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

Re: Version numbers (Was: LONG JAMES v2.4 Road Map)

[Bernd Fondermann <be...@googlemail.com>]

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 <ap...@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