I agree with this. And I think it serves users better, many of whom have migrated to Google Guava.
1) New bug fix only release, JDK 1.4 compatible 2) New release with some generics, backwards compatible 3) Re-evaluate whether an incompatible release makes sense Stephen On 5 August 2011 07:12, Henri Yandell <[email protected]> wrote: > I think we should move the current trunk off and call it generics-RnD. > > Then we should copy 3.2 over to trunk (or maybe 3.3, I seem to recall > that prior to merging the generics in we had a 3.3 ready for release). > > We then release 3.3. > > Then we start 3.4. We genericize some tiny part of it in a binary > compat way. Release. > 3.5. Genericize a bit more. Release. > 3.6... etc. > > We use generics-RnD code, pulling it over (and maybe deleting when > considered happy). > > Somewhere around about 3.28 we can decide to start on 4.0, pulling > over the remainder of generics-RnD. > > Hen > > > On Wed, Aug 3, 2011 at 8:23 AM, Stephen Colebourne <[email protected]> > wrote: >> I think that a key mistake was trying to do both generics and >> refactoring. I'd suggest that quite a few users would simply like a >> generified [collections] 3.5 that is fully backwards compatible (as >> the JDK was) and with no refactoring. >> >> Now, some of the API cannot be generified correctly, so for a v3.5, >> those should simply be left as raw types. >> >> Of course doing the above isn't fun, as it involves going back >> (again), but it it probably the right approach. >> >> Stephen >> >> >> >> On 3 August 2011 16:01, Paul Benedict <[email protected]> wrote: >>> Or do a pure generics release as 3.5 to satisfy that need... which >>> allows 4.0 to have generics plus the benefit of major refactoring if >>> necessary (could also be called 4.0 and 5.0). >>> >>> On Wed, Aug 3, 2011 at 9:55 AM, Matt Benson <[email protected]> wrote: >>>> On Wed, Aug 3, 2011 at 9:48 AM, Gary Gregory <[email protected]> >>>> wrote: >>>>> The most important theme IMO is generics. That's what has come up at >>>>> work recently in fact. Everything else except showstopper bugs can >>>>> wait IMO. >>>> >>>> Indeed, this seems to resonate with Hen's recent treatise on >>>> (paraphrased) why the hell we take so long. >>>> >>>> Matt >>>> >>>>> >>>>> Gary >>>>> >>>>> On Wed, Aug 3, 2011 at 9:16 AM, Simone Tripodi <[email protected]> >>>>> wrote: >>>>>> Hi all guys, >>>>>> I'm (re)starting having a good slot of spare time, I volunteered to >>>>>> help Matt on finalizing the [collections] release, but after had a >>>>>> look at the open issues I think we should agree on what including and >>>>>> what not. >>>>>> Does anyone already have a good overview/idea of collections roadmap? >>>>>> Many thanks in advance, have a nice day!!! >>>>>> Simo >>>>>> >>>>>> http://people.apache.org/~simonetripodi/ >>>>>> http://www.99soft.org/ >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thank you, >>>>> Gary >>>>> >>>>> http://garygregory.wordpress.com/ >>>>> http://garygregory.com/ >>>>> http://people.apache.org/~ggregory/ >>>>> http://twitter.com/GaryGregory >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
