I think this is a pretty important point. Isn't there a tool out there that automatically generates the changes in APIs? I seem to recall seeing one. Perhaps even IntelliJ has one built in? Obviously, one could generate the svn diffs, but that will be too verbose.
-Grant On Apr 27, 2010, at 1:27 AM, Doron Cohen 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]
