mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Webb" <elihusma...@gmail.com>
Subject Re: [About the Filter Chain] Proposals
Date Mon, 03 Nov 2008 15:13:07 GMT
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 <elecharny@gmail.com> 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
>
>
>

Mime
View raw message