commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: svn commit: r1039315 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/linear/ site/xdoc/changes.xml
Date Fri, 26 Nov 2010 21:38:44 GMT
> > > 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.

Of course, the "RealVector" existed. Why would I deprecate new code???

Granted, the methods to be removed should be deprecated, but I take "should"
as "Ideally, if I had the time, I would do it".

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

OK, I don't follow; but I surely hope that you didn't mean that we should
keep the deprecated classes in 3.0.

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

The first part of this sentence, I don't get either.

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

OK. I'm sorry that I misinterpreted your insistence on "micro-commits". I
thought that you'd find it useful to have reference (through the commit log
email) indicating that some methods X were deprecated in revision Y (and
moreover, that revision Y contains only that particular change, and
furthemore that the deprecation message indicates what replaces the
deprecated code).

Now, if you are satisfied with a terse '@deprecated' in the 2.2 branch and
an immediate disappearance in 3.0, that's prefectly fine with me; that makes
more sense and less work.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message