So then we should stop with milestone releases and start pulling code apart and start fixing it. I am also using 2.0 in near-production systems, but if it takes a few more months for a release, I may be stuck with reverting back to 1.1 since I cannot release my system with beta software in it. I am sure that I am not the only person in this situation.
On Mon, Nov 3, 2008 at 10:30 AM, Julien Vermillard <[EMAIL PROTECTED]> wrote: > On Mon, 3 Nov 2008 10:13:07 -0500 > "Mark Webb" <[EMAIL PROTECTED]> wrote: > >> 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 > > Here my point of view on the subject. > > Actually the MINA core code doubled since 1.1 and is quite > difficult to understand. you need to be aware, that if you release 2.0, > there is good chance it'll be hardly maintained because all the internal > code is clumsy, and hard to debug. > > So until deciphering core isn't done (I think Emmanuel will succes) and > we gather a good knowledge we can't release. > > If fixing a bit the monster is breaking some API I'm ready to pay the > price, and I'm actually running M3 in prod. > > If we don't fix some issues like sentMessage, FilterChain and overall > internal documentation, you better be prepared to see this code rot. > >> >> >> 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 >> > >> > >> > >
