commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: [Math] Deprecation in 2.2 (Was: svn commit: r990792 [1/5] - ...)
Date Tue, 31 Aug 2010 16:51:23 GMT
In the Lucene world, there is always a x.9 release that contains all
deprecations for the upcoming release.

It also generally maintains backward compatibility, but includes all new
API's and may change semantics a bit, especially
where the old semantics were demonstrably wrong.  This means that porting to
x.9 takes a tiny bit of effort, but that effort
makes porting to (x+1).0 very easy.

The x.9 release can be viewed as a bridge release ... your code will
probably run and if you get rid of deprecation warnings
moving to the next .0 release will be very easy.

I am sure that a real Lucene person could correct the details, but the basic
idea is correct.  From a user's standpoint, these
x.9 releases are really valuable since it makes conversions doable in small
doses.  Without them, there would be great masses
marooned on old releases.

On Tue, Aug 31, 2010 at 8:50 AM, Phil Steitz <phil.steitz@gmail.com> wrote:

> Gilles Sadowski wrote:
> >>>> These deprecations should go in the 2.x branch.  Version 2.2 will be
> >>>> cut from the 2.x branch, so in order for users to see the
> >>>> deprecation annotation, it needs to be there.
> >>> I hesitated to leave the deprecation indication, the more so that the
> >>> mentioned "IterativeAlgorithm" does not exist yet!
> >>> The issue is far from clear; see
> >>>  https://issues.apache.org/jira/browse/MATH-413
> >>>
> >>> This interface should probably disappear (or go into some other
> package) but
> >>> some classes still depend on it (in package "analysis.solvers").
> >>>
> >> That's fine.  We don't have to decide this yet.  The point that I
> >> was making is that what we should be doing to show intent to remove
> >> things in 3.0 is to add the deprecation annotations to the 2.x
> >> branch.  That way, users will see the deprecation in the 2.2 release.
> >
> > Then, we should agree on the way to go (e.g. for MATH-413) *before* the
> > release of 2.2 so that we can add deprecation warnings in all the classes
> > that might disappear as a result of the refactoring towards 3.0.
> >
> It would be ideal to get all deprecations into 2.2; but I don't
> personally see it as strictly necessary - i.e., we could either cut
> a 2.3 including more deprecations or remove/replace some things in
> 3.0 without having deprecated them in 2.x at all.  Major releases
> can include compatibility breaks.  Deprecation is a good way to give
> users heads up when we know something is going to be removed or
> replaced.  Our policy should be that as soon as we have decided to
> remove or replace something in 3.0, we should deprecated it in the
> 2.x branch.  We should not; however, postpone the 2.x release until
> we are 100% certain about all incompatible changes that we are going
> to make in 3.0.  I am interested in other views on this.
>
> Phil
> >
> > Gilles
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message