On Fri, Nov 26, 2010 at 4:38 PM, Gilles Sadowski < gil...@harfang.homelinux.org> 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. > > 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. > > Sorry, that's what I meant and I misunderstood what you were saying above about new code - you were referring to the replacement methods. Sorry I misunderstood. In any case, I still think it only makes sense to deprecate in a release prior to the one that removes the code, so I would say yes, just remove the code in 3.0 and try to do the deprecations in 2.2. In some cases, the message can only say the method is going to be removed. Phil > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
