[collections] deprecation policty (was Re: [collections] ComparableComparator executes all comparisons twice!?)

[Rodney Waldhoff <rw...@apache.org>]

Please change the subject line when thread veers off the original topic
like this one has.

On Thu, 9 Jan 2003, Ola Berg wrote:

> > ie) Unwanted code is deprecated for the next major or minor release, and
> > removed in the major release following that.
> >
> > so:
> >
> > 1.0 -> 2.0, Foo.foo is deprecated
> > 2.0 -> 2.1, Foo.bar is deprecated
> > 2.1 -> 3.0, Foo.foo and Foo.bar are both removed
> >
> > or if it is such that we just need to do N releases between deprecation
> > and removal, specify that. Basically get something simple and effective
> > standardised to stop future debates.
>
> I'd suggest:
>
> patch number 1.2.1 -> 1.2.2 = bugfix, no API or behavioural changes
>
> minor number 1.2.3 -> 1.3.0 = adding functionality/API, still backwards
> compatible (classes or methods may be added)
>
> major number 2.0.0 -> = risk for backward incompatibilities
>
> With this scheme, the removal of deprecated methods and classes needs a new
> major release number.
>
> /O
>
> --


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>