> you can stub out a method with a print statement that says "don't use this" and still deprecate it.
That’s not deprecation. That’s breaking the method.
To define “works” somewhat more specifically: deprecation means that functionality is not materially altered from how it was before the deprecation. (You might devise some way of notifying users—e.g. DeprecationWarning in Python, #[deprecated] in Rust—but this does not materially alter functionality.)
The January notice was a deprecation (even if they mislabelled it). This notice is not a deprecation, because the service was already deprecated. This notice defines a sunset timeline, but does not alter the parameters of the deprecation.
> That’s not deprecation. That’s breaking the method.
It's both. You can even break a feature and deprecate it for that reason. Deprecation comes down to communication.
> deprecation means that functionality is not materially altered from how it was before the deprecation.
No it doesn't. Maybe you really want it to, but it doesn't.
> This notice is not a deprecation, because the service was already deprecated.
That's not how that works... you can deprecate something and deprecate it again. Each notice is the deprecation if you don't realize this I don't know what you're still going on about...
> you can stub out a method with a print statement that says "don't use this" and still deprecate it.
That’s not deprecation. That’s breaking the method.
To define “works” somewhat more specifically: deprecation means that functionality is not materially altered from how it was before the deprecation. (You might devise some way of notifying users—e.g. DeprecationWarning in Python, #[deprecated] in Rust—but this does not materially alter functionality.)
The January notice was a deprecation (even if they mislabelled it). This notice is not a deprecation, because the service was already deprecated. This notice defines a sunset timeline, but does not alter the parameters of the deprecation.