Add task to check for deprecations

[bonjourmauko]

Follows discussion on #1033
Depended upon by #1045

New features

• Introduce make check-deprecated
  • Allows for listing the features marked as deprecated.

Example:

$ make check-deprecated

[⚙] Check for features marked as deprecated...
[!] commons.dummy.__init__:17 => Deprecated since: 34.7.0. Expiration status: 36.0.0 (current: 36.0.0).
[/] 18%  |█████████·········································|

[bonjourmauko]

As discussed over the phone @MattiSG , I'd need a resolution on this one, as a lot of what is to come for #1061 , #1062 , and #1063 , depends on this.

By the way what I'm proposing here is just a way to soft-deprecate things, not to deprecate them —thus to defer the deprecating thing after the aforementioned issues are complete.

[MattiSG]

While technically exciting, this proposal has a major impact on process: since deprecation checks will be enforced, it means that it will be the responsibility of some future contributor to handle removing deprecated features, without necessarily having the associated knowledge.

To be more concrete: if on October 2021, contributor A ships an improvement along with a deprecation due for version 38; and then in July 2022, contributor B gets a PR accepted for a major change leading to version 38 being released, then they will get an automated check blocking shipping. Contributor A is maybe not available, and no one clearly understands what the deprecation does anymore.
Can we just rely on prior knowledge for deprecation? How can we be sure that contributor B cleanly removes all references to the deprecated feature? How do we let the community know?

I believe this warrants a wider discussion and a community agreement on the deprecation process. The current system is not satisfactory, as depreciations are never followed upon and the codebase is crippled with remnants. However, the proposed system dilutes responsibility and I foresee production problems. To me, it is worth questioning the added value of deprecation under semver: why not just ship a breaking change? Reusers are free to upgrade (or not) whenever they want, and I doubt anyone actually upgrades their code before it breaks. Are the gains in advance notice really worth the added administrative costs, process complexity, and testing code?

[MattiSG]

Not necessary in the CHANGELOG.

[bonjourmauko]

@MattiSG True, but the concrete use-case for me is the one discussed in #1015 : this provides a way to have feature A and B at the same time, so to adapt country template, extension template, and so on.

So while I see the scenario you mention, for me we were not to say "let's deprecate this in 3 majors", but exactly to group deprecations together while working on an epic/theme, and having the time to update dependent libraries.

I agree however in the misuse it can lead to, I see the benefits.

For example, numpy does this kind of soft-deprecation, and we've already received input from users telling us of warnings they're getting from numpy —yes, people who do not filter warnings exist.

So the main concern you address could be expressed as "if I set a deprecation, I should also expire it".

Would making that contract explicit make this better than the actual system for you?

Beyond that, indeed this would greatly benefit from a broader community discussion.

[MattiSG]

Thank you very much for this clear recap and rephrasing. I agree that the “setting a deprecation entails responsibility for expiring it” rule would solve most of my concerns 🙂 Now, with this rule set, how much do you think we need the feature provided by this changeset? While exciting, I’m concerned with the amount of code it adds to maintain. I believe getting more maintainers inputs would be useful, poke @benjello @sandcha.

[bonjourmauko]

A good example of this is #1015 :

• I expired a deprecation
• Tests failed => country template
• PR open in country template to adapt to the new API

The whole in 5m, no need for the intricacies of the past (installing from a branch, etc.).

Clean, easy, repeatable, feedback-driven.

[bonjourmauko]

Did not create consensus.