commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [collections] 4.0 release path
Date Fri, 05 Aug 2011 11:12:27 GMT
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
<scolebourne@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 <flamefew@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
>> <scolebourne@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 <flamefew@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 <scolebourne@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 <pbenedict@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 <gudnabrsam@gmail.com>
wrote:
>>>>>>> On Wed, Aug 3, 2011 at 9:48 AM, Gary Gregory <garydgregory@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 <simonetripodi@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-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message