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...@apache.org> on 2008/05/01 00:00:48 UTC
Re: Big refactoring in MINA 2 or 3?
Hi,
this is pretty well summarized.
I would had some point though : as soon as we freeze the API, we are
going to live with it for months, may be years.
If we differ those importants API modifications, we will also get stuck
with MINA 2 and an increasing number of users, which will be reluctant
to switch to MINA 3. Mina is pretty young, so this is also something we
should consider, as we gain new users every day (see
http://people.apache.org/~vgritsenko/stats/projects/mina.html#Downloads-N1008F).
Maarten Bosteels wrote:
> Hello,
>
> I do agree with everyone who says "anyone using a pre-release is taking a
> risk"
> but I also I agree with Trustin that we should try to avoid hurting our
> users.
>
> In principle: yes, just do these radical changes in 2.0 since we haven't
> gone to RC yet.
> BUT in practice it's a trade-off:
> * how much trouble would we inflict on users that are already using MINA 2.0
> * how much trouble would it cause us to maintain 2.0 and 3.0
>
> I guess we can stop supporting 1.x as soon as 2.0 GA is released ?
>
> AFAICS, work on mina 2.0 started in October 2006 or maybe even earlier
> and a new versioning scheme was defined in November 2006. [1] and [2]
>
> I always thought the idea was of the milestones was "release early, release
> often"
> but 17 months later we have released only one milestone
> (note that I am not blaming anyone for this, except myself for not helping
> out more).
>
> Recently Trustin wrote [3] about the possibility to reach 2.0 RC1 in the
> near future.
> I think we should go for it because :
> * it would please a lot of users
> * supporting them might be easier when we have an RC (or a GA)
> * we would get more feedback from people using 2.0
> * which could lead to more ideas for improving 3.0
> * less time pressure when we can work on these 'big changes" in 3.0
>
> [1] http://markmail.org/message/iup4sfwyecalsdyd
> [2] http://markmail.org/message/hymzddmoteiatcwq
> [3] http://www.nabble.com/Issues-to-resolve-for-2.0.0-(GA)-td16872513.html
>
> regards,
> Maarten
>
> On Wed, Apr 30, 2008 at 7:28 PM, Kevin Williams <ke...@gmail.com> wrote:
>
>
>> On Wed, Apr 30, 2008 at 9:18 AM, "이희승 (Trustin Lee) <tr...@gmail.com>
>> wrote:
>>
>>> ..... However, I
>>> realized it can be somewhat irresponsible action to our users who
>>> already are using MINA 2 in their production system. If they are going
>>> to spend many sleepless nights because of the radical changes, we're
>>> likely to lose a part of our precious community.
>>>
>> Frankly, anyone using a pre-release product in their production code
>> is accepting some risk of it changing, whether they know it or not. I
>> wouldn't worry about it.
>>
>>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Big refactoring in MINA 2 or 3?
Posted by Frédéric Brégier <fr...@free.fr>.
Hi Emmanuel !
Yes, it's may 1rst, probably why I wrote so many mails... ;-)
I agree with your points.
I will see how I can contribute and what could be the organization
for this specific point (doc).
PS: And finaly, yes, I'm Français... ;-) (French in other word)
Probably why I made sooo long mail... (hoping to be clear however)
Frederic
----- Original Message -----
From: "Emmanuel Lecharny"
Sent: Thursday, May 01, 2008 1:17 PM
Subject: Re: Big refactoring in MINA 2 or 3?
Hi buddy...
Sh*t, man, it's may 1st :)
Frederic Bregier wrote:
> But what message should be sent to end-users ?
> - Use 1.X version only for production
> - Use 2.X (or later) only for test purpose
The clear message should be 1.1.7 is production ready, and 2.0-M1 is a
milestone, so don't expect it to be production ready, wait for 2.0.0
> I believe that 2.X is almost mature (except of course current threads
> on refactoring) ;-)
yeap, me too.
> And I perfectly understand that contributors want end-users to use 2.X
> version
> (at least to enable to not maintain until end of time past versions).
> So I would suggest something like:
> "V1.X should be used if API changes are unwanted but at the price of
> no evolution except bug corrections"
> "V2.X should be used _at your own risk_ considering API can change due
> to evolutions, new features and improvement"
> "Trunk version should be used only in testing environment"
> WDYT ?
In fact, 2.0-M1 is for testing purpose. Trunk is the dev branch. Both
are targeting 2.0-RC1.
>
> On the contribution part, I am not sure of my skill, so contributing
> on web pages or docs (through dev list as I done before)
> is probably the best I can do.
Any contribution is ok. Don't be scared, we are not genious :)
This has been something that always stroke me : people tend to think
Apache committers as half god, or kind of. Nothing is farther from the
reality than this fairy tale ! We are just passionate, and do our best
to contribute to this common effort. What make us better than others is
the community : the ASF help us not to make too many mistakes, people
(like you) help us to fix those mistakes, and at the end of the day, if
we are humble enough to accept ideas, advises and help, that makes good
software.
Please feel free to post what you feel can be usefull, you are very
welcome !
> For instance, I will not be probably as good as other contributors on
> this kind
> of code (bytebuffers and relative). However, if (as in the past) I see
> something, I will mail the dev list... ;-)
That the way it works :)
>
> Perhaps when you (contributors) will decide your way, you can setup a
> JIRA for doc issue on this
> and I can (as others) fill it ?
That's a good idea. We don't have this kind of JIRA, but we may ask for it.
Thanks a lot !
PS: Français ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Big refactoring in MINA 2 or 3?
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi buddy...
Sh*t, man, it's may 1st :)
Frederic Bregier wrote:
> But what message should be sent to end-users ?
> - Use 1.X version only for production
> - Use 2.X (or later) only for test purpose
The clear message should be 1.1.7 is production ready, and 2.0-M1 is a
milestone, so don't expect it to be production ready, wait for 2.0.0
> I believe that 2.X is almost mature (except of course current threads
> on refactoring) ;-)
yeap, me too.
> And I perfectly understand that contributors want end-users to use 2.X
> version
> (at least to enable to not maintain until end of time past versions).
> So I would suggest something like:
> "V1.X should be used if API changes are unwanted but at the price of
> no evolution except bug corrections"
> "V2.X should be used _at your own risk_ considering API can change due
> to evolutions, new features and improvement"
> "Trunk version should be used only in testing environment"
> WDYT ?
In fact, 2.0-M1 is for testing purpose. Trunk is the dev branch. Both
are targeting 2.0-RC1.
>
> On the contribution part, I am not sure of my skill, so contributing
> on web pages or docs (through dev list as I done before)
> is probably the best I can do.
Any contribution is ok. Don't be scared, we are not genious :)
This has been something that always stroke me : people tend to think
Apache committers as half god, or kind of. Nothing is farther from the
reality than this fairy tale ! We are just passionate, and do our best
to contribute to this common effort. What make us better than others is
the community : the ASF help us not to make too many mistakes, people
(like you) help us to fix those mistakes, and at the end of the day, if
we are humble enough to accept ideas, advises and help, that makes good
software.
Please feel free to post what you feel can be usefull, you are very
welcome !
> For instance, I will not be probably as good as other contributors on
> this kind
> of code (bytebuffers and relative). However, if (as in the past) I see
> something, I will mail the dev list... ;-)
That the way it works :)
>
> Perhaps when you (contributors) will decide your way, you can setup a
> JIRA for doc issue on this
> and I can (as others) fill it ?
That's a good idea. We don't have this kind of JIRA, but we may ask for it.
Thanks a lot !
PS: Français ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
AW: [SPAMCheck] Re: Big refactoring in MINA 2 or 3?
Posted by Steve Ulrich <st...@proemion.com>.
Hi!
I agree with you. We are using Mina 2.0-M1 for production and had used the pre-M1 versions already. But it is, what its name says: a milestone/a prerelease. So I don't see any problems in that change. Any code deployed with such a version have to be double checked for problems. An API change is something that you will recognize at compile time, so what? ;)
Additionally, the structures of mina doesn't change that much, IMHO. Maybe you can add a pre-2.0-M2 compatibility filter that maps the new buffer/stream/whatever to a IoBuffer/ByteBuffer, so that a step-by-step migration is possible. It won't be the fastest solution but it may help to migrate if someone really have problems with that.
regards
Steve
> Frederic Bregier [mailto:fred.bregier@free.fr] wrote
>
> Hi Emmanuel,
> Just a short mail. I really appreciate your points !
> I agree that no one can ensure production release, even M$ !
> I like your sentence : "Use it _at your own risk_"
> But what message should be sent to end-users ?
> - Use 1.X version only for production
> - Use 2.X (or later) only for test purpose
> I believe that 2.X is almost mature (except of course current threads
> on
> refactoring) ;-)
> And I perfectly understand that contributors want end-users to use 2.X
> version
> (at least to enable to not maintain until end of time past versions).
> So I would suggest something like:
> "V1.X should be used if API changes are unwanted but at the price of no
> evolution except bug corrections"
> "V2.X should be used _at your own risk_ considering API can change due
> to evolutions, new features and improvement"
> "Trunk version should be used only in testing environment"
> WDYT ?
>
> On the contribution part, I am not sure of my skill, so contributing on
> web pages or docs (through dev list as I done before)
> is probably the best I can do. For instance, I will not be probably as
> good as other contributors on this kind
> of code (bytebuffers and relative). However, if (as in the past) I see
> something, I will mail the dev list... ;-)
>
> Perhaps when you (contributors) will decide your way, you can setup a
> JIRA for doc issue on this
> and I can (as others) fill it ?
>
> Frederic
>
> Emmanuel Lecharny a écrit :
> > Hi Frederic,
> >
> > Frederic Bregier wrote:
> >> Hello all,
> >> I am a final user. A few days ago I already wrote something on this.
> >> As I said, I knew that Mina-2.M1 is not stable and could change.
> >> However, the dev-list says also that all users should migrate to
> >> Mina-2-M1
> > That is a mistake, IMO. Sadly, many projects do the very same
> mistake,
> > just because people are enthousistic and think that the last commit
> > made the code so wonderfull ...
> >> even if it is not stable (from API point of view) since it should be
> >> more stable (in production point of view).
> >>
> >> I don't agree when some say "anyone using a pre-release is taking a
> >> risk",
> > You may not agree, but this is a simple fact : you are taking a risk,
> > even with the release versions. Even M$ explicitly says in his legal
> > document that they don't assume any damage their product can cause...
> >> specially when all contributors say that users should migrate to 2-
> M1.
> > Don't trust contributors ;)
> >> Of course, those users are informed that the API could change.
> >> So, from this point of view, I accept this risk.
> >> But, if you suggest that production environment should only use
> >> 1.X version, so nobody will go to version 2...
> >> Again, from my point of view, there are two kind of stability :
> >> - API stability : all users are informed that Version 2 is not
> >> currently stable but likely
> >> - production stability : all users are encouraged to use Version 2
> >> instead of V1.X
> > This is not exactly what 'stable' means. Here you are :
> > - a released version is API stable AND production ready (sort of ...)
> > - a RC is API stable but may not be totally production ready
> > - a minor version (1.y, 2.y, ...) is API stable in any case, except
> > the added features (which may be extensions to the API, not
> > modification of the existing API).
> > - any other versions are *not* stable *nor* production ready
> >
> > So unless you download the released version, you are on risk, and
> > whatever the contributors says, this is an optimistic vision of this
> > reality. Sorry for that.
> >>
> >> So did I...
> >> As Geoff said before, my resolution of this problem would be to fix
> >> my own version
> >> (from trunk) of Mina 2 in my project (in production) in order to
> keep
> >> a "stable" API version
> >> and to release this "fix" version with my project.
> >> And from time to time (from 2 years now I did that), I will migrate
> >> to newer version
> >> and revalidate all my project (no-regression tests).
> > That's the best way to handle versions, IMO. This is also why I
> > insisted that as soon as a release is launched, it will last for
> > _years_, so better be sure that we have the correct API.
> >
> > Will you be happy to have a MINA release every year with a completely
> > reworked API each time ?
> >> Of course, as Geoff, whatever the decision is made, I will continue
> >> to use Mina and probably
> >> getting as much as possible to the newest version, but at my speed,
> >> not yours.
> > Just plain fair. And the contributors task is to help you to do so,
> > providing migration guides, answers to your questions, etc.
> >> I already had to migrate from 1.0, to 1.X, to trunk before 2M1, to
> >> trunk after 2M1.
> >> So it should be not a problem for me.
> > At some point, you may want to contribute to the project :)
> >>
> >> I would suggest that in order to limit the pain of final users you
> >> maintain a web page
> >> with all necessary doc (howto) on migration to version 2M1 to
> >> whatever version
> >> numbered scheme you choose (2MX, 2 RC, or 3).
> > This is an excellent idea, but it's totally irrealistic for migration
> > between Mx and My... Unless a kind user provide such a page ;)
> >>
> >> Keep you very good job continuing, but please try to not loose your
> >> users...
> >> At least, don't publish negative information like one can
> >> misunderstood some
> >> post as "don't use V2 on production".
> > The message should be : "Use it _at your own risk_" !
> >> For me, it is a non sense.
> >> As Julien said, I understand that maintain several versions (1.0,
> >> 1.X, 2.0M1, ...)
> >> at the same time can be very painful ! But therefore, try to get a
> >> smooth
> >> movement for end-users.
> >>
> >> Finally, if it is not clear (sometimes I am not), I really love
> Mina.
> > Thanks :)
> >> I will obviously continue to use it and I can perhaps help on this
> >> particular web-page,
> >> at least on some part (by sending at least some mails into this
> >> dev-list for instance).
> > That would be very cool ! We don't have a lot of coders, and even
> less
> > documenters... every contribution is really appreciated !
> >
> >
> > A last word : it sounds like, as we are a open source project, we
> > don't really care about users, but nothing can be more wrong. The
> > problem is that we may spread wrong messages, and as convos are
> > conducted done on the ML, and as we do make mistakes (a lot !), the
> > messages might be fuzzy or misleading. The *big* difference with
> > closed source projects is that you can see when we do mistakes, it's
> > not hidden behind some massive marketing wall. Please excuse us in
> > this case ;)
> >
> > Thanks a lot for using MINA and for being supportive !
> >
> > PS: we didn't stated on what we will do, btw. We may still release
> > 2.0-RC as is.
> >
Re: Big refactoring in MINA 2 or 3?
Posted by Frederic Bregier <fr...@free.fr>.
Hi Emmanuel,
Just a short mail. I really appreciate your points !
I agree that no one can ensure production release, even M$ !
I like your sentence : "Use it _at your own risk_"
But what message should be sent to end-users ?
- Use 1.X version only for production
- Use 2.X (or later) only for test purpose
I believe that 2.X is almost mature (except of course current threads on
refactoring) ;-)
And I perfectly understand that contributors want end-users to use 2.X
version
(at least to enable to not maintain until end of time past versions).
So I would suggest something like:
"V1.X should be used if API changes are unwanted but at the price of no
evolution except bug corrections"
"V2.X should be used _at your own risk_ considering API can change due
to evolutions, new features and improvement"
"Trunk version should be used only in testing environment"
WDYT ?
On the contribution part, I am not sure of my skill, so contributing on
web pages or docs (through dev list as I done before)
is probably the best I can do. For instance, I will not be probably as
good as other contributors on this kind
of code (bytebuffers and relative). However, if (as in the past) I see
something, I will mail the dev list... ;-)
Perhaps when you (contributors) will decide your way, you can setup a
JIRA for doc issue on this
and I can (as others) fill it ?
Frederic
Emmanuel Lecharny a écrit :
> Hi Frederic,
>
> Frederic Bregier wrote:
>> Hello all,
>> I am a final user. A few days ago I already wrote something on this.
>> As I said, I knew that Mina-2.M1 is not stable and could change.
>> However, the dev-list says also that all users should migrate to
>> Mina-2-M1
> That is a mistake, IMO. Sadly, many projects do the very same mistake,
> just because people are enthousistic and think that the last commit
> made the code so wonderfull ...
>> even if it is not stable (from API point of view) since it should be
>> more stable (in production point of view).
>>
>> I don't agree when some say "anyone using a pre-release is taking a
>> risk",
> You may not agree, but this is a simple fact : you are taking a risk,
> even with the release versions. Even M$ explicitly says in his legal
> document that they don't assume any damage their product can cause...
>> specially when all contributors say that users should migrate to 2-M1.
> Don't trust contributors ;)
>> Of course, those users are informed that the API could change.
>> So, from this point of view, I accept this risk.
>> But, if you suggest that production environment should only use
>> 1.X version, so nobody will go to version 2...
>> Again, from my point of view, there are two kind of stability :
>> - API stability : all users are informed that Version 2 is not
>> currently stable but likely
>> - production stability : all users are encouraged to use Version 2
>> instead of V1.X
> This is not exactly what 'stable' means. Here you are :
> - a released version is API stable AND production ready (sort of ...)
> - a RC is API stable but may not be totally production ready
> - a minor version (1.y, 2.y, ...) is API stable in any case, except
> the added features (which may be extensions to the API, not
> modification of the existing API).
> - any other versions are *not* stable *nor* production ready
>
> So unless you download the released version, you are on risk, and
> whatever the contributors says, this is an optimistic vision of this
> reality. Sorry for that.
>>
>> So did I...
>> As Geoff said before, my resolution of this problem would be to fix
>> my own version
>> (from trunk) of Mina 2 in my project (in production) in order to keep
>> a "stable" API version
>> and to release this "fix" version with my project.
>> And from time to time (from 2 years now I did that), I will migrate
>> to newer version
>> and revalidate all my project (no-regression tests).
> That's the best way to handle versions, IMO. This is also why I
> insisted that as soon as a release is launched, it will last for
> _years_, so better be sure that we have the correct API.
>
> Will you be happy to have a MINA release every year with a completely
> reworked API each time ?
>> Of course, as Geoff, whatever the decision is made, I will continue
>> to use Mina and probably
>> getting as much as possible to the newest version, but at my speed,
>> not yours.
> Just plain fair. And the contributors task is to help you to do so,
> providing migration guides, answers to your questions, etc.
>> I already had to migrate from 1.0, to 1.X, to trunk before 2M1, to
>> trunk after 2M1.
>> So it should be not a problem for me.
> At some point, you may want to contribute to the project :)
>>
>> I would suggest that in order to limit the pain of final users you
>> maintain a web page
>> with all necessary doc (howto) on migration to version 2M1 to
>> whatever version
>> numbered scheme you choose (2MX, 2 RC, or 3).
> This is an excellent idea, but it's totally irrealistic for migration
> between Mx and My... Unless a kind user provide such a page ;)
>>
>> Keep you very good job continuing, but please try to not loose your
>> users...
>> At least, don't publish negative information like one can
>> misunderstood some
>> post as "don't use V2 on production".
> The message should be : "Use it _at your own risk_" !
>> For me, it is a non sense.
>> As Julien said, I understand that maintain several versions (1.0,
>> 1.X, 2.0M1, ...)
>> at the same time can be very painful ! But therefore, try to get a
>> smooth
>> movement for end-users.
>>
>> Finally, if it is not clear (sometimes I am not), I really love Mina.
> Thanks :)
>> I will obviously continue to use it and I can perhaps help on this
>> particular web-page,
>> at least on some part (by sending at least some mails into this
>> dev-list for instance).
> That would be very cool ! We don't have a lot of coders, and even less
> documenters... every contribution is really appreciated !
>
>
> A last word : it sounds like, as we are a open source project, we
> don't really care about users, but nothing can be more wrong. The
> problem is that we may spread wrong messages, and as convos are
> conducted done on the ML, and as we do make mistakes (a lot !), the
> messages might be fuzzy or misleading. The *big* difference with
> closed source projects is that you can see when we do mistakes, it's
> not hidden behind some massive marketing wall. Please excuse us in
> this case ;)
>
> Thanks a lot for using MINA and for being supportive !
>
> PS: we didn't stated on what we will do, btw. We may still release
> 2.0-RC as is.
>
Re: Big refactoring in MINA 2 or 3?
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi Frederic,
Frederic Bregier wrote:
> Hello all,
> I am a final user. A few days ago I already wrote something on this.
> As I said, I knew that Mina-2.M1 is not stable and could change.
> However, the dev-list says also that all users should migrate to
> Mina-2-M1
That is a mistake, IMO. Sadly, many projects do the very same mistake,
just because people are enthousistic and think that the last commit made
the code so wonderfull ...
> even if it is not stable (from API point of view) since it should be
> more stable (in production point of view).
>
> I don't agree when some say "anyone using a pre-release is taking a
> risk",
You may not agree, but this is a simple fact : you are taking a risk,
even with the release versions. Even M$ explicitly says in his legal
document that they don't assume any damage their product can cause...
> specially when all contributors say that users should migrate to 2-M1.
Don't trust contributors ;)
> Of course, those users are informed that the API could change.
> So, from this point of view, I accept this risk.
> But, if you suggest that production environment should only use
> 1.X version, so nobody will go to version 2...
> Again, from my point of view, there are two kind of stability :
> - API stability : all users are informed that Version 2 is not
> currently stable but likely
> - production stability : all users are encouraged to use Version 2
> instead of V1.X
This is not exactly what 'stable' means. Here you are :
- a released version is API stable AND production ready (sort of ...)
- a RC is API stable but may not be totally production ready
- a minor version (1.y, 2.y, ...) is API stable in any case, except the
added features (which may be extensions to the API, not modification of
the existing API).
- any other versions are *not* stable *nor* production ready
So unless you download the released version, you are on risk, and
whatever the contributors says, this is an optimistic vision of this
reality. Sorry for that.
>
> So did I...
> As Geoff said before, my resolution of this problem would be to fix my
> own version
> (from trunk) of Mina 2 in my project (in production) in order to keep
> a "stable" API version
> and to release this "fix" version with my project.
> And from time to time (from 2 years now I did that), I will migrate to
> newer version
> and revalidate all my project (no-regression tests).
That's the best way to handle versions, IMO. This is also why I insisted
that as soon as a release is launched, it will last for _years_, so
better be sure that we have the correct API.
Will you be happy to have a MINA release every year with a completely
reworked API each time ?
> Of course, as Geoff, whatever the decision is made, I will continue to
> use Mina and probably
> getting as much as possible to the newest version, but at my speed,
> not yours.
Just plain fair. And the contributors task is to help you to do so,
providing migration guides, answers to your questions, etc.
> I already had to migrate from 1.0, to 1.X, to trunk before 2M1, to
> trunk after 2M1.
> So it should be not a problem for me.
At some point, you may want to contribute to the project :)
>
> I would suggest that in order to limit the pain of final users you
> maintain a web page
> with all necessary doc (howto) on migration to version 2M1 to whatever
> version
> numbered scheme you choose (2MX, 2 RC, or 3).
This is an excellent idea, but it's totally irrealistic for migration
between Mx and My... Unless a kind user provide such a page ;)
>
> Keep you very good job continuing, but please try to not loose your
> users...
> At least, don't publish negative information like one can
> misunderstood some
> post as "don't use V2 on production".
The message should be : "Use it _at your own risk_" !
> For me, it is a non sense.
> As Julien said, I understand that maintain several versions (1.0, 1.X,
> 2.0M1, ...)
> at the same time can be very painful ! But therefore, try to get a smooth
> movement for end-users.
>
> Finally, if it is not clear (sometimes I am not), I really love Mina.
Thanks :)
> I will obviously continue to use it and I can perhaps help on this
> particular web-page,
> at least on some part (by sending at least some mails into this
> dev-list for instance).
That would be very cool ! We don't have a lot of coders, and even less
documenters... every contribution is really appreciated !
A last word : it sounds like, as we are a open source project, we don't
really care about users, but nothing can be more wrong. The problem is
that we may spread wrong messages, and as convos are conducted done on
the ML, and as we do make mistakes (a lot !), the messages might be
fuzzy or misleading. The *big* difference with closed source projects is
that you can see when we do mistakes, it's not hidden behind some
massive marketing wall. Please excuse us in this case ;)
Thanks a lot for using MINA and for being supportive !
PS: we didn't stated on what we will do, btw. We may still release
2.0-RC as is.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Big refactoring in MINA 2 or 3?
Posted by Frederic Bregier <fr...@free.fr>.
Hello all,
I am a final user. A few days ago I already wrote something on this.
As I said, I knew that Mina-2.M1 is not stable and could change.
However, the dev-list says also that all users should migrate to Mina-2-M1
even if it is not stable (from API point of view) since it should be
more stable (in production point of view).
I don't agree when some say "anyone using a pre-release is taking a risk",
specially when all contributors say that users should migrate to 2-M1.
Of course, those users are informed that the API could change.
So, from this point of view, I accept this risk.
But, if you suggest that production environment should only use
1.X version, so nobody will go to version 2...
Again, from my point of view, there are two kind of stability :
- API stability : all users are informed that Version 2 is not currently
stable but likely
- production stability : all users are encouraged to use Version 2
instead of V1.X
So did I...
As Geoff said before, my resolution of this problem would be to fix my
own version
(from trunk) of Mina 2 in my project (in production) in order to keep a
"stable" API version
and to release this "fix" version with my project.
And from time to time (from 2 years now I did that), I will migrate to
newer version
and revalidate all my project (no-regression tests).
Of course, as Geoff, whatever the decision is made, I will continue to
use Mina and probably
getting as much as possible to the newest version, but at my speed, not
yours.
I already had to migrate from 1.0, to 1.X, to trunk before 2M1, to trunk
after 2M1.
So it should be not a problem for me.
I would suggest that in order to limit the pain of final users you
maintain a web page
with all necessary doc (howto) on migration to version 2M1 to whatever
version
numbered scheme you choose (2MX, 2 RC, or 3).
Keep you very good job continuing, but please try to not loose your users...
At least, don't publish negative information like one can misunderstood some
post as "don't use V2 on production". For me, it is a non sense.
As Julien said, I understand that maintain several versions (1.0, 1.X,
2.0M1, ...)
at the same time can be very painful ! But therefore, try to get a smooth
movement for end-users.
Finally, if it is not clear (sometimes I am not), I really love Mina.
I will obviously continue to use it and I can perhaps help on this
particular web-page,
at least on some part (by sending at least some mails into this dev-list
for instance).
Frederic
Emmanuel Lecharny a écrit :
> Hi,
>
> this is pretty well summarized.
>
> I would had some point though : as soon as we freeze the API, we are
> going to live with it for months, may be years.
>
> If we differ those importants API modifications, we will also get
> stuck with MINA 2 and an increasing number of users, which will be
> reluctant to switch to MINA 3. Mina is pretty young, so this is also
> something we should consider, as we gain new users every day (see
> http://people.apache.org/~vgritsenko/stats/projects/mina.html#Downloads-N1008F).
>
>
> Maarten Bosteels wrote:
>> Hello,
>>
>> I do agree with everyone who says "anyone using a pre-release is
>> taking a
>> risk"
>> but I also I agree with Trustin that we should try to avoid hurting our
>> users.
>>
>> In principle: yes, just do these radical changes in 2.0 since we
>> haven't
>> gone to RC yet.
>> BUT in practice it's a trade-off:
>> * how much trouble would we inflict on users that are already using
>> MINA 2.0
>> * how much trouble would it cause us to maintain 2.0 and 3.0
>>
>> I guess we can stop supporting 1.x as soon as 2.0 GA is released ?
>>
>> AFAICS, work on mina 2.0 started in October 2006 or maybe even earlier
>> and a new versioning scheme was defined in November 2006. [1] and [2]
>>
>> I always thought the idea was of the milestones was "release early,
>> release
>> often"
>> but 17 months later we have released only one milestone
>> (note that I am not blaming anyone for this, except myself for not
>> helping
>> out more).
>>
>> Recently Trustin wrote [3] about the possibility to reach 2.0 RC1 in the
>> near future.
>> I think we should go for it because :
>> * it would please a lot of users
>> * supporting them might be easier when we have an RC (or a GA)
>> * we would get more feedback from people using 2.0
>> * which could lead to more ideas for improving 3.0
>> * less time pressure when we can work on these 'big changes" in 3.0
>>
>> [1] http://markmail.org/message/iup4sfwyecalsdyd
>> [2] http://markmail.org/message/hymzddmoteiatcwq
>> [3]
>> http://www.nabble.com/Issues-to-resolve-for-2.0.0-(GA)-td16872513.html
>>
>> regards,
>> Maarten
>>
>> On Wed, Apr 30, 2008 at 7:28 PM, Kevin Williams <ke...@gmail.com>
>> wrote:
>>
>>
>>> On Wed, Apr 30, 2008 at 9:18 AM, "이희승 (Trustin Lee)
>>> <tr...@gmail.com>
>>> wrote:
>>>
>>>> ..... However, I
>>>> realized it can be somewhat irresponsible action to our users who
>>>> already are using MINA 2 in their production system. If they are
>>>> going
>>>> to spend many sleepless nights because of the radical changes, we're
>>>> likely to lose a part of our precious community.
>>>>
>>> Frankly, anyone using a pre-release product in their production code
>>> is accepting some risk of it changing, whether they know it or not. I
>>> wouldn't worry about it.
>>>
>>>
>
>