Frequent (one a year is very very frequent) backwards incompatible API changes lead to no users. If ya'll take this roadmap I, for one, will go find some library which isn't going to dead end me in the *foreseeable* future.
-Brian On Wed, Jun 11, 2008 at 10:09 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > peter royal wrote: > >> On Jun 11, 2008, at 9:07 AM, Emmanuel Lecharny wrote: >> >>> we have discussed both options a month ago, and there were quite a >>> concensus to get these changes into a postponed 2.0, instead of delivering a >>> 2.0 and including changes into a 3.0. >>> >>> Now the environment has changed a bit in the last few weeks, and we have >>> a lot of thing to do in order to get a 2.0 out, even if we don't include the >>> ByteBuffer rewrite. >>> >>> IMHO, we can go for a documented 2.0 for the moment (and it will take a >>> while), and start a branch for 3.0. >>> >> >> whoops! silly me for missing that :) must have been buried in a thread i >> glazed over :) >> >> anyways, yes, i agree with a documented and cleaned up 2.0, with more >> substantial changes in a separate branch for the time being. we've been >> promising 2.0 for a LOOONG time, so i think we owe it to the community to >> deliver upon that. >> >> -pete >> > I have also started a thread about NIO 2.0 (expected soon for Java 7), I > was wondering if we can't define a long term roadmap where, for instance : > 2.0 : expected by Q3/Q4 2008, with the current trunk content, documented > and decyphered, > 3.0 : somewhere in 2009, with the new ByteBuffer implementation (and other > things to be defined) > 4.0 : Support for NIO 2.0 (or may be another name like MINA2, I don't > know). Not that Java 7 is widely used right now, I don't even think that > more than 50% of the Java users have switched to Java 6 yet, but it's good > to give ome visibility to our users ... > > wdyt ? > > > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
