+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
