05/11/2021 22:33, Ferruh Yigit: > On 11/5/2021 4:26 PM, Stephen Hemminger wrote: > > On Fri, 05 Nov 2021 16:05:14 +0100 > > Thomas Monjalon <tho...@monjalon.net> wrote: > > > >>>>> > >>>>> What do you think about marking old macros as deprecated? > >>>>> > >>>>> This will cause warning in application code that is using > >>>>> old macros, but shouldn't fail their build (unless -Werror > >>>>> is issued). > >>>> > >>>> It looks to be the right thing to do. > >>>> I wonder whether we could wait 22.02 to apply it, > >>>> so users of LTS are not annoyed by it. > >>> > >>> I have no strong opinion, but tend to agree with Thomas. > >>> However, if an application jumps from LTS to LTS, these > >>> defines will be available in 21.11 without any warnings > >>> and simply disappear in 22.11. So, may be it is more > >>> friendly to deprecate in 21.11. > >> > >> That's true for a lot of deprecations done in the year. > >> Jumping from LTS to LTS is for production. > >> Intermediate releases should help in the upgrade preparation process. > > > > Agree, the deprecation cycle is long enough and it is just a > > trivial warning easy to fix, or for those that ignore warnings > > they just won't care. > > > > I think Thomas is suggesting to postpone the patch to v22.02, is it > what you agree? > > If so, plan is: > - Have v21.11 without this patch. So backward compatibility macros > won't be deprecated in v21.11, and end users won't be affected > from the rename at all. > - v22.02 will have this patch that deprecates the old macros. End > user will get build warnings after this point. > - Remove deprecated macros on v22.11. If this time is agreed on, > I will send a deprecation notice patch for it.
That's exactly my thinking.
