You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2006/11/08 07:02:01 UTC
Milestones and Release Candidates
Hi all,
As we've discussed in dev@directory.apache.org, the current version
numbering scheme has the following issues:
Even/odd semantic can't handle pre-releases when the major version number
increases (e.g. 1.8 -> 2.0). It seems like Linux kernel is using '-pre'
suffix to work around this issue:
http://ftp.cdut.edu.cn/pub2/linux/kernel/history/Master.html
1a. Start working in 1.9 first.
1b. As we resolve issues, we find that we need major changes in the API.
1c. Start to use '-preX' suffix (e.g. 1.9.8 -> 2.0-pre1)
This version numbering scheme works, but we also need to take a look into an
alternative, Milestones and Release Candidates
We start from M1. We can change whatever we want in milestone phase. Once
we think the API is stabilized, we move to RC1. We keep fixing visible bugs
reported by users in this phase. If we are confident that its API design
and stability, we release without any suffix (i.e. the official point
release).
The advantage of this scheme is that any newcomer can understand it without
any prior knowledge. It is because Milestone and Release Candidate has
clearer meaning comparing to even/odd numbers.
What do you think about each scheme? Which scheme do you prefer? Do you
have other scheme in mind? Please let me know!
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Milestones and Release Candidates
Posted by Emmanuel Lecharny <el...@gmail.com>.
Well, using the same scheme that Eclipse does sound good to me :
M1, M2, ... Mn untill all features for a version has been implemented. Each
milestone is just used to deliver e preview of some features, being clear
that all the features are known
RC1..RCn are release candidate. Sounds pretty ok.
So, if you use Milestone instead of odd numbers I think it will work without
any probleem, and the semantic might be quite clear.
Just a last point : when moving form a X.Y to a X.Y+1, do deprecate the old
API, do not remove it. You can remove them in X+1.Y (just a question of
easing the migration ;)
To be short, +1
Re: Milestones and Release Candidates
Posted by Julien Vermillard <jv...@archean.fr>.
Hi
After speaking with Trustin, we thought about :
Keep a trunk in SVN until all feature aren't implemented, when it's not
too crappy, start releasing beta, when it's looking releasable, start an
RC cycle.
It keep the user well informed about the fact it's not a stable prog and
no alpha and pre-alpha cycles, prevent Trusting of firing a vote
everyday :)
WDYT ?
Julien
Le jeudi 09 novembre 2006 à 00:11 +0900, Trustin Lee a écrit :
> On 11/8/06, Alex Karasulu <ao...@bellsouth.net> wrote:
> >
> > Maarten Bosteels wrote:
> >
> > > So a big +1 from me.
> >
> > A binding -1 from me with respect to the even/odd scheme. We already
> > discussed these issues. And I don't think trustin is abandoning that in
> > this email. He's just interested in using pre- which might be a good
> > idea.
>
>
> I think the discussion was for ApacheDS and we need to discuss again for
> MINA because there were a few opinions regarding the alternative schemes.
> ApacheDS is a feature-driven stand alone server software but MINA is a
> framework. I think it worths to discuss from the different point of view.
>
> >> 1a. Start working in 1.9 first.
> > >> 1b. As we resolve issues, we find that we need major changes in the
> > API.
> > >> 1c. Start to use '-preX' suffix (e.g. 1.9.8 -> 2.0-pre1)
> >
> > This sounds fine with me. We can have pre and a rc for the release
> > candidates.
>
>
> then pre means milestone in the alternative scheme. I just feel like we are
> mixing too many expressions. It's just a version number, but we need to
> keep it simple and straightforward. Even, Odd, pre, rc, ... isn't it too
> much for just a number?
>
> >> This version numbering scheme works, but we also need to take a look into
> > >> an
> > >> alternative, Milestones and Release Candidates
> >
> > Hmmm you're starting to mix different release models. I agree with
> > release candidates.
>
>
> Actually this model is from Eclipse. Majority of projects are using this
> scheme although there are some variations like beta.
>
> Trustin
RE: Milestones and Release Candidates
Posted by "Irving, Dave" <da...@logicacmg.com>.
Trustin Lee wrote:
...
> I just feel like we are mixing too many expressions. It's just a
version number,
> but we need to keep it simple and straightforward.
> Even, Odd, pre, rc, ... isn't it too much for just a number?
...
Some people have mentioned the eclipse versioning style...
Personally, I very much like the M1, M2,.. RC1, RC2,... versioning style
- its simple and expressive.
I'd definitely be +1 for a move over to this sort of versioning scheme.
Dave
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Re: Milestones and Release Candidates
Posted by Trustin Lee <tr...@gmail.com>.
On 11/8/06, Alex Karasulu <ao...@bellsouth.net> wrote:
>
> Maarten Bosteels wrote:
>
> > So a big +1 from me.
>
> A binding -1 from me with respect to the even/odd scheme. We already
> discussed these issues. And I don't think trustin is abandoning that in
> this email. He's just interested in using pre- which might be a good
> idea.
I think the discussion was for ApacheDS and we need to discuss again for
MINA because there were a few opinions regarding the alternative schemes.
ApacheDS is a feature-driven stand alone server software but MINA is a
framework. I think it worths to discuss from the different point of view.
>> 1a. Start working in 1.9 first.
> >> 1b. As we resolve issues, we find that we need major changes in the
> API.
> >> 1c. Start to use '-preX' suffix (e.g. 1.9.8 -> 2.0-pre1)
>
> This sounds fine with me. We can have pre and a rc for the release
> candidates.
then pre means milestone in the alternative scheme. I just feel like we are
mixing too many expressions. It's just a version number, but we need to
keep it simple and straightforward. Even, Odd, pre, rc, ... isn't it too
much for just a number?
>> This version numbering scheme works, but we also need to take a look into
> >> an
> >> alternative, Milestones and Release Candidates
>
> Hmmm you're starting to mix different release models. I agree with
> release candidates.
Actually this model is from Eclipse. Majority of projects are using this
scheme although there are some variations like beta.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Milestones and Release Candidates
Posted by Alex Karasulu <ao...@bellsouth.net>.
Maarten Bosteels wrote:
> So a big +1 from me.
A binding -1 from me with respect to the even/odd scheme. We already
discussed these issues. And I don't think trustin is abandoning that in
this email. He's just interested in using pre- which might be a good idea.
Alex
> Maarten
>
> On 11/8/06, Trustin Lee <tr...@gmail.com> wrote:
>>
>> Hi all,
>>
>> As we've discussed in dev@directory.apache.org, the current version
>> numbering scheme has the following issues:
>>
>> Even/odd semantic can't handle pre-releases when the major version number
>> increases (e.g. 1.8 -> 2.0). It seems like Linux kernel is using '-pre'
>> suffix to work around this issue:
>>
>> http://ftp.cdut.edu.cn/pub2/linux/kernel/history/Master.html
>>
>> 1a. Start working in 1.9 first.
>> 1b. As we resolve issues, we find that we need major changes in the API.
>> 1c. Start to use '-preX' suffix (e.g. 1.9.8 -> 2.0-pre1)
This sounds fine with me. We can have pre and a rc for the release
candidates.
>>
>> This version numbering scheme works, but we also need to take a look into
>> an
>> alternative, Milestones and Release Candidates
Hmmm you're starting to mix different release models. I agree with
release candidates.
Alex
Re: Milestones and Release Candidates
Posted by Maarten Bosteels <mb...@gmail.com>.
I think this is a great idea ! I have always found the odd/even sheme a bit
odd :-)
In the previous thread there were some posts (by non-committers I think)
suggesting to abandon it.
I guess there are a lot more people familiar with the M1 => M2 => ... => RC1
=> RC2 => ... => final
scheme than with the odd/even stuff.
So a big +1 from me.
Maarten
On 11/8/06, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi all,
>
> As we've discussed in dev@directory.apache.org, the current version
> numbering scheme has the following issues:
>
> Even/odd semantic can't handle pre-releases when the major version number
> increases (e.g. 1.8 -> 2.0). It seems like Linux kernel is using '-pre'
> suffix to work around this issue:
>
> http://ftp.cdut.edu.cn/pub2/linux/kernel/history/Master.html
>
> 1a. Start working in 1.9 first.
> 1b. As we resolve issues, we find that we need major changes in the API.
> 1c. Start to use '-preX' suffix (e.g. 1.9.8 -> 2.0-pre1)
>
> This version numbering scheme works, but we also need to take a look into
> an
> alternative, Milestones and Release Candidates
>
> We start from M1. We can change whatever we want in milestone
> phase. Once
> we think the API is stabilized, we move to RC1. We keep fixing visible
> bugs
> reported by users in this phase. If we are confident that its API design
> and stability, we release without any suffix (i.e. the official point
> release).
>
> The advantage of this scheme is that any newcomer can understand it
> without
> any prior knowledge. It is because Milestone and Release Candidate has
> clearer meaning comparing to even/odd numbers.
>
> What do you think about each scheme? Which scheme do you prefer? Do you
> have other scheme in mind? Please let me know!
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
>
>