commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [primitives] First steps
Date Wed, 15 Oct 2003 21:44:57 GMT
The '1' in the middle was a +1 in case there was any doubt. My web email
program strips the plus sign :-(

Stephen

----- Original Message -----
From: <scolebourne@btopenworld.com>
To: <commons-dev@jakarta.apache.org>
Sent: Wednesday, October 15, 2003 5:38 PM
Subject: Re: [primitives] First steps


> >  from:    Rodney Waldhoff <rwaldhoff@apache.org>
> > > 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


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


Mime
View raw message