I don't mind multiple releases with (2), thats a see how it goes type approach. Stephen
On 5 August 2011 08:38, Henri Yandell <[email protected]> wrote: > Repeating myself just to make sure you're in full agreement; there > would be multiple releases within your 2) state. ie) Maybe we > genericize one method and then release [to take it to extremes]. > > Hen > > On Fri, Aug 5, 2011 at 12:33 AM, Stephen Colebourne > <[email protected]> wrote: >> 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] >> >> > > --------------------------------------------------------------------- > 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]
