> from: Rodney Waldhoff <[EMAIL PROTECTED]> > > 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. 1, makes sense.
> > 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? My reasoning is that there will probably be a number of changes to come on [primitives]. Notably, releasing a commons-primitives jar when the classes are in a collections base package seems strange. However I'm not completely averse to it being a 1.0. The code stability and usefulness justifies it. The next release then becomes 2.0, with package adjustments etc. (and the 1.0 packages deprecated). 3.0 then tidies everything up. The only alternative would be to sort out the package renaming, code generation and other arguments now, but that would delay the release too long in reality. So, lets 1.0. I'm happy to tidy up the files to reference 1.0 rather than 0.1. Did you want to take the release manager role for primitives :-)? Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
