You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Edouard De Oliveira <do...@yahoo.fr> on 2008/11/18 14:23:28 UTC
Re : [Votes] MINA 2.0-RC1
[x] Freeze the code, move to MINA 2.0-RC1
> Get 2.0 out, let users migrate, drop 1.0 and 1.1.
+1 1.0 and 1.1 have been supported some significant time moreover generally speaking 1.0 to 2.0 is a breeze
and imporves perfs so we can consider that our users can migrate fast and at a low cost.
This will allow on focusing a big road map for 3.0 maybe hitting some 2.1,2.2 on the road to progressively
introduce some changes and see how community reacts to them.
We need clear roadmaps and timeframes to pinpoint a 'real' goal and make it real.
My 2 cents
Cordialement, Regards,
-Edouard De Oliveira-
http://tedorg.free.fr/en/main.php
________________________________
De : Eero Nevalainen <ee...@indagon.com>
À : dev@mina.apache.org
Envoyé le : Mardi, 18 Novembre 2008, 12h49mn 29s
Objet : Re: [Votes] MINA 2.0-RC1
Emmanuel Lecharny wrote:
> [] Continue to add new features to MINA 2.0 milestones until we reach a stable point
> [] Freeze the code, move to MINA 2.0-RC1
> [] I abstain
Non-binding
[x] Freeze the code, move to MINA 2.0-RC1
Get 2.0 out, let users migrate, drop 1.0 and 1.1.
-- Eero Nevalainen
Re: Re : Re : [Votes] MINA 2.0-RC1
Posted by Emmanuel Lecharny <el...@gmail.com>.
Maarten Bosteels wrote:
> [x] Freeze the code, move to MINA 2.0-RC1
>
> But I agree with Julien, that the docs should improve before going to RC
>
We just have to define a clear roadmap for doco. What about releasing
2.0.0-M4, and fix the doco for 2.0.0-RC1 ?
> -1 for "using a N.5 for unstable versions, and N.0 for stable versions."
>
Ok.
> I really dislike conventions based on numbers. We already discussed this in
> the past : http://mina.markmail.org/message/hymzddmoteiatcwq
> Milestone -> Release Candidate -> General Availability is a well know
> version naming scheme
> It's described here: http://mina.apache.org/downloads.html
>
Well, if it has already been discussed, forget it. No need to rehash
things over and over...
Thanks Maarten !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Re : Re : [Votes] MINA 2.0-RC1
Posted by Emmanuel Lecharny <el...@gmail.com>.
[x] Freeze the code, move to MINA 2.0-RC1
But if we can freeze in M4, and work on doco for RC1, that would be fine !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Re : Re : [Votes] MINA 2.0-RC1
Posted by Maarten Bosteels <mb...@gmail.com>.
[x] Freeze the code, move to MINA 2.0-RC1
But I agree with Julien, that the docs should improve before going to RC
-1 for "using a N.5 for unstable versions, and N.0 for stable versions."
I really dislike conventions based on numbers. We already discussed this in
the past : http://mina.markmail.org/message/hymzddmoteiatcwq
Milestone -> Release Candidate -> General Availability is a well know
version naming scheme
It's described here: http://mina.apache.org/downloads.html
I really don't see why we would change the version naming scheme again.
Of course it's a matter of taste so we can have long discussions about it
... (not sure that it would be productive though)
regards,
Maarten
On Tue, Nov 18, 2008 at 2:53 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Edouard De Oliveira wrote:
>
>> By drawing aside N.1 and N.2 do you mean we will only do bug fixes on the
>> 2.0 branch and new features will only go to 2.5 branch ? I'm not saying i
>> disagree i just want to make your statement more clear.
>>
>>
> This is exactly what I have in mind. However, it's just a convention. It's
> all about the message we want to carry to our users.
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: Re : Re : [Votes] MINA 2.0-RC1
Posted by Emmanuel Lecharny <el...@gmail.com>.
Edouard De Oliveira wrote:
> By drawing aside N.1 and N.2 do you mean we will only do bug fixes on the 2.0 branch and new features will only
> go to 2.5 branch ? I'm not saying i disagree i just want to make your statement more clear.
>
This is exactly what I have in mind. However, it's just a convention.
It's all about the message we want to carry to our users.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re : Re : [Votes] MINA 2.0-RC1
Posted by Edouard De Oliveira <do...@yahoo.fr>.
You're right using a N.5 notation for instable work in progress is ok to me
2.0.0-Mx should indeed be used for an almost frozen API (sometimes minor changes that can't be postponed are needed)
N.0.x are and should be bug fixes
By drawing aside N.1 and N.2 do you mean we will only do bug fixes on the 2.0 branch and new features will only
go to 2.5 branch ? I'm not saying i disagree i just want to make your statement more clear.
Cordialement, Regards,
-Edouard De Oliveira-
http://tedorg.free.fr/en/main.php
________________________________
De : Emmanuel Lecharny <el...@gmail.com>
À : dev@mina.apache.org
Envoyé le : Mardi, 18 Novembre 2008, 14h32mn 17s
Objet : Re: Re : [Votes] MINA 2.0-RC1
> This will allow on focusing a big road map for 3.0 maybe hitting some 2.1,2.2 on the road to progressively introduce some changes and see how community reacts to them.
>
May I suggest that we use a clear notation for 'unstable' versions? With the current one (ie, 2.0.0-Mx), people tend to think that it's stable (stable <=> API is frozen).
What about using a N.5 for unstable versions, and N.0 for stable versions? For instance,
2.5 will be unstable, and will be renamed 3.0-RC1 as soon as we have frozen the API.
IMO, having N.1, N.2 etc is not necessarily a good idea. There is some confusion between N.0 and N.1 versions, as N.0.x are already bug fixes.
-- --
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Re : [Votes] MINA 2.0-RC1
Posted by Emmanuel Lecharny <el...@gmail.com>.
> This will allow on focusing a big road map for 3.0 maybe hitting some 2.1,2.2 on the road to progressively
> introduce some changes and see how community reacts to them.
>
May I suggest that we use a clear notation for 'unstable' versions? With
the current one (ie, 2.0.0-Mx), people tend to think that it's stable
(stable <=> API is frozen).
What about using a N.5 for unstable versions, and N.0 for stable
versions? For instance,
2.5 will be unstable, and will be renamed 3.0-RC1 as soon as we have
frozen the API.
IMO, having N.1, N.2 etc is not necessarily a good idea. There is some
confusion between N.0 and N.1 versions, as N.0.x are already bug fixes.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org