Re: [Math] Deprecation in 2.2 (Was: svn commit: r990792 [1/5] - ...)

[Rahul Akolkar <ra...@gmail.com>]

On Tue, Aug 31, 2010 at 12:51 PM, Ted Dunning <te...@gmail.com> wrote:
> 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.
>
<snip/>

It'd be neat if something along the lines of the above is done here
for all major releases, but as noted below, I'd say its not strictly
necessary. Ofcourse it depends on whether the RM(s) have the necessary
enthusiasm to cut another lead up release, but there is also a sliding
scale in my mind based on how widespread the use of the library is and
how "low level" the API is -- so something like [logging] and [lang]
would be well served by this if the RM(s) had the time and interest.

-Rahul



> On Tue, Aug 31, 2010 at 8:50 AM, Phil Steitz <ph...@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