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.
