commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <>
Subject Re: [primitives] First steps
Date Wed, 15 Oct 2003 13:22:54 GMT
Releasing a 1.0 is going to create unnecessary headaches when dealing 
with backwards compatibility.  I think it's apparent that, at a minimum, 
some of the package names are going to change.  I don't like the idea of 
releasing anything that is going to change soon afterwards.  Why create 
the extra work for ourselves?

Nobody is saying that the primitives code isn't production ready.  It 
just seems that the code needs some room to grow before a 1.0 is released.

Rodney Waldhoff wrote:
> On Tue, 14 Oct 2003, Stephen Colebourne wrote:
>>Are you certain that this makes sense from a commons perspective? To release
>>a version of collections with these classes in only to immediately remove
> Yes, but I think you misunderstand me.  The nightly builds have contained
> collections.primitives for nearly a year.  The maven -SNAPSHOT build has
> as well. To suddenly drop those classes from those JARs seems
> unnecessarily abrubt.  Why not:
> 1) Deprecate commons.collections.primitives, with pointers to
> commons.primitives
> 2) Upload a dated maven snapshot and -SNAPSHOT JARs with that version
> before removing the classes from commons-collections.
> This warns users of the change, and gives a binary equivalent to what
> their used to.  Quick and painless and I'll take care of it.
>>The proposed 0.1 release of primitives has exactly the same classes, in the
>>same packages, unaltered. The only change for a user of nightly builds is to
>>add/move to a different jar file.
>>This recognises that there are nightly build users to be looked after (who I
>>would venture to say actually have relatively few rights in terms of
>>complaining about compatability). These users have some change to cope with
>>yes, but one that is trivial to deal with (a new jar file).  This seems
>>entirely reasonable to me.
>>A 0.1 release of primitives is ready to go as far as I can see. It just
>>waits a vote, plus a release manager. Is there a reason not to do this?
> Calling this release 0.1 suggests it's about an order of magnitude less
> production ready than it is.  Why not 1.0?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message