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 thin
MAIL PROTECTED]>
À : 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
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 conve
[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.
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 versio
[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
