mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [About the Filter Chain] Proposals
Date Mon, 03 Nov 2008 15:06:05 GMT
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

View raw message