On Fri, Nov 26, 2010 at 12:49 PM, Gilles Sadowski < gil...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
