> > > 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. Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
