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
