On Wed, Apr 30, 2008 at 8:18 AM, "이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
> Hi folks, > > As some of you already know, I proposed somewhat radical changes in our > current core API of MINA 2. At the first time, I though all the changes > I proposed can be made before we release MINA 2 GA. However, after a > couple of long IRC conversations and e-mail discussions, I realized it's > not something that can happen within a few months. It's rather what we > need to approach very carefully, as Emmanuel pointed out. > > Moreover, we already released MINA 2.0.0-M1 and recommended our users to > use it saying its core API is not likely to change and transport > implementation is very stable. Of course, we didn't enter RC yet, so > it's not obviously wrong for us to make such big changes. 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. > > Therefore, I thought it might be a better idea to maintain the current > API and release GA as planned and to continue our experimentation in a > separate branch. WDYT? Does it sound saner? :) > For me personally an API change such as the one being discussed would cause a decent amount of pain. Granted there has been no declared api freeze and no RC releases, but I believe there has been enough said to lead users to believe that the 2.0 API would remain relatively stable. Just a few days ago Trustin was disussing issues that need to be resolved prior to a GA release here http://www.nabble.com/Issues-to-resolve-for-2.0.0-(GA)-to16872513.html If the proposed changes were implemented I don't think I would have any other choice but to fork the current trunk and maintain my own version until 2.0 was final and I had time to upgrade. Whatever decision is made it won't cause me to stop using MINA. :-) -geoff
