Hi all guys, I would *personally* avoid all that amount of work, people already migrated to google-collections/guava so I wouldn't invest efforts on providing releases incrementally, but rather focused on a fresh new release that could attract again users that left us. Just my small 2cents, Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Aug 5, 2011 at 11:32 AM, Stephen Colebourne <scolebou...@joda.org> wrote: > 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 <flame...@gmail.com> 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 >> <scolebou...@joda.org> 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 <flame...@gmail.com> 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 <scolebou...@joda.org> >>>> 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 <pbened...@apache.org> 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 <gudnabr...@gmail.com> wrote: >>>>>>> On Wed, Aug 3, 2011 at 9:48 AM, Gary Gregory <garydgreg...@gmail.com> >>>>>>> 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 >>>>>>>> <simonetrip...@apache.org> 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: dev-unsubscr...@commons.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thank you, >>>>>>>> Gary >>>>>>>> >>>>>>>> http://garygregory.wordpress.com/ >>>>>>>> http://garygregory.com/ >>>>>>>> http://people.apache.org/~ggregory/ >>>>>>>> http://twitter.com/GaryGregory >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
