proxmox: deprecate old compatibility feature flag

[russoz]

SUMMARY

Deprecate parameter proxmox_default_behavior added in version 1.3.0.

ISSUE TYPE

• Refactoring Pull Request

COMPONENT NAME

plugins/modules/proxmox.py

[ansibullbot]

cc @Ajpantuso @Thulium-Drake @UnderGreen @joshainglis @karmab @tleguern
click here for bot help

[felixfontein]

How about bumping the deprecation to c.g 10.0.0? That gives users some more time to do the adjustment.

[russoz]

How about bumping the deprecation to c.g 10.0.0? That gives users some more time to do the adjustment.

That's starting to look like a norm, @felixfontein :)

Personally I think this has been around and documented for a long time. Users should/would not be using compatibility behaviour in a long time. Those who eventually are had to make that choice after reading the docs, so they should be aware.

For this case I would prefer to solve it sooner rather than later.

[felixfontein]

Removing options where there's no pressing need to remove them should IMO have a longer deprecation period. It's OK IMO to warn them about the upcoming deprecation, complete removal is another level. If you would only deprecate and remove the compatibility value of this option I think 9.0.0 is fine. But it could be that quite some users explicitly added this option explicitly with value no_defaults some time ago, and now they are 'punished' for doing that by giving them a short timeframe to remove it again.

[russoz]

IMO 1+ year is not a "short timeframe", but not pressing the point. Bumping up to 10.0.0.

[patchback]

Backport to stable-7: 💚 backport PR created

✅ Backport PR branch: patchback/backports/stable-7/c34a22717e40a532529e0283c973881f4f8530b6/pr-6836

Backported as #6851

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

[felixfontein]

@russoz @UnderGreen thanks!