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:[EMAIL PROTECTED] 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. > >
