I was reading a post about PHP deprecation.
And I was thinking why bother developers with more errors.
Why throw a deprecation message
The most common cause is a change in the codebase. The other frequent cause is when the language provides a build-in alternative for functionality in the codebase.
When it is a language change a deprecation message is necessary until the codebase supports the language version as the minimum requirement.
With the codebase change the choice isn't that obvious anymore.
I think the main reason to make the change is when other parts of the code benefit from it. The big question is does that benefit warrants a new major version or it small enough to only have a minor version bump?
When the benefit is in a minor version, then the question becomes when will the previous way of working be removed. The deprecation message shouldn't span multiple major versions, because then blindness for the message sets in.
Upgrade paths
There are a few upgrade paths that I see;
- Keep maintaining different versions: I don't see a need for deprecation errors here.
- Create a final minor version with the API breaking changes:This is the version that contains the deprecation errors.
- Provide an automated refactor possibility with the next major version: For example in PHP that can be a Rector configuration. Here I don't see the need for deprecation errors either.
Of course it is not that there is no need that there are no circumstances where deprecation errors can be beneficial.
For example when the decision is made to sunset an older version in the multiple version way of working, then a final version could be made with deprecation errors.
Conclusion
As with everything in IT deprecation is a solution for a specific problem, and it shouldn't be used as a silver bullet.
The period of showing the deprecation messages should be as short as possible for the maximum effect.
Top comments (0)