Squee wrote:
As a user of Mina, I agree 100% on releasing 2.0 without all of these
big changes, and pushing them down to a 3.0 release. While I'm
perfectly willing and able to update my app code if 2.0 API changes (I
expected as much when I chose to go with 2.0), it's still nice to be
using fully released software, rather than pre-release-candidate
stuff. (Not that I've had any issues at all.)
...on my side, I think releasing more with a minor release (like 2.0.1
or something like that) will help adoption. I'm not sure about how this
community execute release, but I'm pretty convinced that as soon as you
say you have an official release, more peoples will go back here instead
of hunting bears...
I think releasing using 2.x.x and more often will be beneficial. At
least it works fine in Grizzly and it increase the buzz around the
framework (hiding all the API deficiencies ;-))
A+
-- Jeanfrancois
On Mon, Nov 3, 2008 at 9:38 AM, Niklas Gustavsson <[EMAIL PROTECTED]> wrote:
On Mon, Nov 3, 2008 at 4:13 PM, 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.
Big +1. We will find areas that we would like to improve during the
foreseeable future (this change and ByteBuffer comes to mind).
Including all such changes will delay 2.0 for a long time, long enough
for MINA to get behind other frameworks. Having a real release out
will mean getting further feedback from users, so far I haven't seen a
lot of users requesting this change nor the ByteBuffer change. I think
we're too critical, the code is great. Release early, release often.
We do neither.
I would think that we should move right
towards 3.0.
I say go work on a branch (as already suggested) and see where that leads.
/niklas
