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 <[EMAIL PROTECTED]>
wrote:
On Wed, Apr 30, 2008 at 9:18 AM, "이희승 (Trustin Lee)
<[EMAIL PROTECTED]>
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.
