The only correction to this example is... It's entirely possible m2 was backported to stable, and users see this on upgrading to the next minor release.
It's only for changes that are not back-ported to stable where this example applies, and I agree -- we have to do a strong job documenting the migration for these trunk(unstable)-only changes. Mike On Tue, Apr 27, 2010 at 1:27 AM, Doron Cohen <[email protected]> wrote: > +1 > > I would like to note (and depict) one aspect of this change (although it is > most probably clear to active followers of these threads). > Deprecation warnings had been quite useful for users when upgrading to a > *major* release. > The voted change cancels them. > Example follows. > Picture the following state in the "new Lucene life cycle": > Stable is "feeding" release 8. > Most recent minor release is 8.4. > Trunk will soon "feed" release 9, > In 8.4 there is method m1(x). > In trunk, m1(x) is renamed to m2(x,y). > With this suggestion, in trunk, m1(x) is dropped and m2(x,y) is introduced. > No deprecations! > In stable, that is 8, no change is introduced at all - it is not possible to > put a deprecate warning there since m2(x,y) is not there. > Now, when 9.0 is finally cut from stable and released, we will *not* first > cut 8.last with deprecation warning, because that usually goes with > implementing the deprecated logic using the non-deprecated one, which is (a) > not always feasible and (b) a burden that this whole change is trying to > avoid. > So, from now on, deprecation warnings would not be there to help users when > upgrading to the next major release. > Only documentation would guide them. > Therefore, when committing such a change, it would be very important to > adequately update the tbd evolving upgrade guide. > Doron --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
