Hi all, I am not part of the process of Mina construction, I am just an end user. I try to follow your discussion and I mostly agree with your points.
I have however one concern, OK, it is personnal one, but probably I could be not the only one. I know that Mina2 M1 API is not stable and could change in RC. But I would suggest to create one specific "help" page to migrate from 2-M1 (or trunk) to 2-RC when it will be released, and starting this doc from early revision (M2, M3, ...). Why ? Because you often suggested to use the 2M1 version instead of 1.X version (for obvious reasons of improvement). And now, as an end user, I just published the V1.0 (ready for production) version of my project using the Mina 2 (pre-M2 version so from trunk). Of course, I had taken into account that V2 can change in API, but I would like that those changes can be done with respect with end user, so the documentation. In order to be independant, I always join "my stable" version of Mina so I am independent of Mina's roadmap. >From time to time, I update the project to use more recent version of Mina. Of course, if you think it can be useful, I can help on this doc, since I would probably get into it whatever the doc exists or not. But on the counter part, I don't used all part of Mina, so probably I could miss some parts... This was just my 2 cents of contribution. But please go ahead to improve Mina, as always ! Frederic Selon "\"ì´í¬ì¹ (Trustin Lee)" : > Emmanuel Lecharny wrote: > > "ì´í¬ì¹ (Trustin Lee) <[EMAIL PROTECTED]>" wrote: > >> So.. The changes I am proposing is all about simplification sacrificing > >> backward compatibility. This might affect people who are using MINA 2 > >> M1 or trunk. We had to think about all these issues before recommending > >> people to use 2 M1 and placing the download links in the very top of the > >> download page. (we could move the links to the unstable releases > >> section.) > >> > > The problem is that we already have people who are using MINA 2. Now, > > the question is : should we release it and go for a MINA 3 with a > > completely new API, or should we change MINA 2 API now before we release > > it as a RC... > > > > That's not a simple question. > > > > My personnal choice would be to do it now, before MINA is widely used. > > We never said that MINA 2 API was stable. As soon as we deliver the > > first RC, we are done. > > > > Another option (and may be better) would be to deprecate dead API (but > > that means we still have to guarantee some compatibility... No fun at > > all !) > > I concur with you. I'd prefer to make the changes in M2. > > -- > Trustin Lee - Principal Software Engineer, JBoss, Red Hat > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > >
