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
