commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: svn commit: r1039315 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/linear/RealVector.java site/xdoc/changes.xml
Date Fri, 26 Nov 2010 18:19:59 GMT
On Fri, Nov 26, 2010 at 12:49 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:

> On Fri, Nov 26, 2010 at 12:14:33PM -0500, Phil Steitz wrote:
> > The deprecations below are in the wrong source tree.   They need to be
> > applied to the 2.x branch and unless it is just as a signal to those
> > building (dangerously) from trunk, I do not see the point of deprecating
> in
> > the 3.0 branch.
>
> This was done on purpose, in order to have one revision containing the
> deprecation message before actually removing the code.
> That way, someone can possibly get the files with the deprecation tags
> and copy them over to the 2.x branch.
>

So these are new files added only to the 3.0 branch?  In that case, no need
to deprecate as they have never been released.   But looking carefully at
the commit, I can see these are at least mostly 2.1 methods, so they
*should* be deprecated in the 2.x branch.

>
> > I am -0 on applying these to the 3.0 branch, since the code should be
> > removed before release (i.e., the code should simply be removed in the
> 3.0
> > branch) and -1 on applying them to 3.0 without first applying to 2.x.
> > Please either apply to 2.x or revert.
>
> Revert what?
>

I meant revert the commit.

>
> I'll copy the files as suggested above, but the information in there will
> be
> inconsistent (e.g. the replacement classes are *not* in the branch).


In that case, there is no need to deprecate in either branch, but in at
least most cases in this commit, the deprecated methods exist in 2.1, which
means they should be deprecated in the 2.2 release.

Luc
> already said that it was a nightmare to keep the branches in sync. [I do
> not
> have time for that. I mean: I do not have time for that.]
> Luc also indicated that 2.2 will/should be considered as a maintenance
> release: Users will be able to stick with 2.2 or upgrade to 3.0, but will
> not be able able to make all their code compatible with 3.0 while running
> on
> 2.2.
>

I agree with that.  We have also agreed that we should try as best we can to
deprecate the methods and classes that are going to be removed in 3.0.  It
makes no sense to do those deprecations in the 3.0 source tree without
applying them to the 2.x branch as that is the branch that will form the
basis for the release that should contain the deprecations.  If you have no
time to do the deprecations in the proper branch, then don't waste time
doing them in the 3.0 branch.  It will be even more confusing to users when
they mysteriously vanish when you subsequently remove the code in the 3.0
branch and  Luc or I miss the clean up in preparing the 2.2 release.

Lets agree to either fully deprecate as we remove things of just remove code
and leave the cleanup to the lucky RM for 2.2.

Phil

>
>
> Gilles
>
> ---------------------------------------------------------------------
> 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