I think we should focus on getting 2.0 out the door. We have been working on it long enough and I think there are many people using it in production or near-production systems. Once we release, we will probably get alot more feedback and can use that feedback to enhance/fix the next version. I would think that we should move right towards 3.0.
As we get closer and closer to a release, I think the API should not change and therefore we should not be adding functionality into the system unless something is really broke. just my $.02 Mark On Mon, Nov 3, 2008 at 10:06 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Mark Webb wrote: >> >> I agree that we should not 'slaughter' the current code since we are >> getting close to a final 2.0 release. >> > > This is something we have to discuss. Here, IMHO, we have two options, both > have pros and cons : > > 1) go as far as needed to get a MINA 2.0 with as much cleaning as needed. > 2) Release MINA 2.0 as fast as possible, fixing the most obvious bugs, and > move directly to a MINA 3.0 > > Option (1) pros : > - as MINA 2.0 API is not stabilized yet (we are still working on milestone), > this let use the opportunity to do those changes with a minimal harm > - we can do that now, not waiting for a 2.0 release to be done in, say, 2 > months > - this is the perfect opportunity to clean up the code, add the missing > documentation, and delivering a much better release > > Option (1) cons : > - it will takes months before we can release a long waited new release > - many users are already using mina 2.0, and they will be unpleased if we > change a lot of things into it > - we have to be careful not to remove any of the existing functionalities, > something we don't have to take care for a 3.0 branch, as it won't be used > in production before quite a long time > > Option (2) pros : > - freedom ! No need to care about the existing code, we can even start from > a white page. > - the community can grow faster, as we may have people who are reluctant to > enter the project while it's in a pre-release state > - we are not limited in time. 2.0 is expected sooner or later, with a 3.0, > we have more than a year to get something done > > Option (2) cons : > - we will have to maintain a 2.0 version which is far from being perfect > - 2.0 seems to be slow, compared to other framework. Not that important > IMHO, but releasing a dog is not the perfect way to get some good reports... > - people who are expecting a better MINA (a simpler one) might wait for one > more year until 3.0 is out. Even worse, they can run away... > > Of course, I'm just dumping some of the ideas I have about that. atm, I have > not yet set my mind on which option is the best, but we can still work with > both options in mind, as soon as what we do is done in a branch. Soon, we > will be able to decide if we release a 2.0 with or without those > modifications, and then merge the branch into trunk or create a new version, > closing the 2.0 branch (ie : it will become a release branch). > > In any case, there is something very important : the current code base is > not known by a lot of people, and it will take time to build a new community > around the core code base. The biggest question is : will we find enough > people wanting to work on the current trunk in order to get the new release > (be it 2.0 or 3.0) ? And how long will they be dedicated ? What if we > release a 2.0-RC in the next few months and as we don't have anyone wanting > to start a 3.0 ? > > so, now, wdyt ? > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
