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.
