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 them?
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?
Stephen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
