You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2008/11/18 12:04:14 UTC
[Votes] MINA 2.0-RC1
Hi guys,
I think it's time to stop discussing for ever and to start a vote.
MINA 2.0.0-Mx is around for months now, and we have more and more users
developing applications around it. We have tons of proposal to improve
MINA, but many of them are pretty drastic, and may jeopardize our users'
investment. OTOS, if we close MINA 2.0 now, we also close the door to
some very important features and improvement we want to have in MINA,
which will be differed for months if we start a 3.0.
So the best would be to determinate which strategy should be the best.
Here is a proposal.
[] 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
If we select (1), we will have to determinate the clear roadmap,
otherwise we won't be able to release 2.0 before 2017...
If we pick (2), we have to check the open JIRAs, fix them, and define a
timeframe for 2.0-RC1 release (and it should be a matter of weeks, not
months)
Guys, it's up to you !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Votes] MINA 2.0-RC1
Posted by Elihu Smails <el...@gmail.com>.
[X] Freeze the code, move to MINA 2.0-RC1
On Tue, Nov 18, 2008 at 6:04 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi guys,
>
> I think it's time to stop discussing for ever and to start a vote.
>
> MINA 2.0.0-Mx is around for months now, and we have more and more users
> developing applications around it. We have tons of proposal to improve MINA,
> but many of them are pretty drastic, and may jeopardize our users'
> investment. OTOS, if we close MINA 2.0 now, we also close the door to some
> very important features and improvement we want to have in MINA, which will
> be differed for months if we start a 3.0.
>
> So the best would be to determinate which strategy should be the best. Here
> is a proposal.
>
> [] 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
>
> If we select (1), we will have to determinate the clear roadmap, otherwise
> we won't be able to release 2.0 before 2017...
> If we pick (2), we have to check the open JIRAs, fix them, and define a
> timeframe for 2.0-RC1 release (and it should be a matter of weeks, not
> months)
>
> Guys, it's up to you !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
RE: [Votes] MINA 2.0-RC1
Posted by Steve Ulrich <st...@proemion.com>.
> Emmanuel Lecharny [mailto:elecharny@gmail.com] wrote:
>
> [] Continue to add new features to MINA 2.0 milestones until we reach a
> stable point
> [X] Freeze the code, move to MINA 2.0-RC1
> [] I abstain
>
> If we select (1), we will have to determinate the clear roadmap,
> otherwise we won't be able to release 2.0 before 2017...
A clear roadmap for 3.0 would be fine, too.
Even if the roadmap isn't met, its a point where you can head to.
regards
Steve
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
Re : [Votes] MINA 2.0-RC1
Posted by Edouard De Oliveira <do...@yahoo.fr>.
[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: [Votes] MINA 2.0-RC1
Posted by Eero Nevalainen <ee...@indagon.com>.
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: [Votes] MINA 2.0-RC1
Posted by Ashish <pa...@gmail.com>.
[X] Freeze the code, move to MINA 2.0-RC1
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [Votes] MINA 2.0-RC1
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Nov 18, 2008 at 12:04 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> [X] Freeze the code, move to MINA 2.0-RC1
Let's go!
/niklas
Re:
Posted by Jeff Genender <jg...@apache.org>.
[X] Freeze the code, move to MINA 2.0-RC1
On Nov 18, 2008, at 4:04 AM, wrote:
> Hi guys,
>
> I think it's time to stop discussing for ever and to start a vote.
>
> MINA 2.0.0-Mx is around for months now, and we have more and more
> users developing applications around it. We have tons of proposal to
> improve MINA, but many of them are pretty drastic, and may
> jeopardize our users' investment. OTOS, if we close MINA 2.0 now, we
> also close the door to some very important features and improvement
> we want to have in MINA, which will be differed for months if we
> start a 3.0.
>
> So the best would be to determinate which strategy should be the
> best. Here is a proposal.
>
> [] 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
>
> If we select (1), we will have to determinate the clear roadmap,
> otherwise we won't be able to release 2.0 before 2017...
> If we pick (2), we have to check the open JIRAs, fix them, and
> define a timeframe for 2.0-RC1 release (and it should be a matter of
> weeks, not months)
>
> Guys, it's up to you !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
Re: [Votes] MINA 2.0-RC1
Posted by Julien Vermillard <jv...@archean.fr>.
On Tue, 18 Nov 2008 12:04:14 +0100
Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi guys,
>
> I think it's time to stop discussing for ever and to start a vote.
>
> MINA 2.0.0-Mx is around for months now, and we have more and more
> users developing applications around it. We have tons of proposal to
> improve MINA, but many of them are pretty drastic, and may jeopardize
> our users' investment. OTOS, if we close MINA 2.0 now, we also close
> the door to some very important features and improvement we want to
> have in MINA, which will be differed for months if we start a 3.0.
>
> So the best would be to determinate which strategy should be the
> best. Here is a proposal.
> [snip..]
> [] Continue to add new features to MINA 2.0 milestones until we reach
> a stable point
> [X] Freeze the code, move to MINA 2.0-RC1
> [] I abstain
>
> [snip..]
Agreeing on feature freeze but until doc isn't better no way to release
an RC.
Julien