On Fri, Aug 5, 2011 at 5:55 AM, Gary Gregory wrote:
> On Fri, Aug 5, 2011 at 2:12 AM, Henri Yandell 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
On Fri, Aug 5, 2011 at 2:12 AM, Henri Yandell 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.
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
h
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 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 the
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
wrote:
> I agree with this. And I think it ser
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, H
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 bina
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
Thanks all for the feedbacks!!!
I think that having generics (already done for what I can see) plus
COLLECTIONS-310/351/372/377 + checking all issues where requesting
generics would be reasonable to publish the 4.0 release.
I don't know if someone already has a complete list of COLLECTIONS-310
rel
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 wrote:
> On Wed, Aug 3, 2011 at 9:48 AM, Gary Gregory wrote:
>> The mo
On Wed, Aug 3, 2011 at 9:48 AM, Gary Gregory 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 ta
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.
Gary
On Wed, Aug 3, 2011 at 9:16 AM, Simone Tripodi wrote:
> Hi all guys,
> I'm (re)starting having a good slot of spare time, I volunteered to
> help
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?
M
13 matches
Mail list logo
