Hello, hope everyone is doing good. I have a question about deprecation cycles: does promoting a deprecated declaration to error level is an incompatible API change accordingly to the Semantic Versioning Specifications ? As far as I understand, promoting a deprecated declaration to this level could be considered to an incompatible API change because it breaks the consumer's source code by failing its compilation if the declaration is used. But it could also be a compatible change because it doesn't change the ABI of the package... Thank you for considering answering this question and have a great week-end.

It depends. If you just upgrade dependency in classpath - deprecation doesn't affect it at all. But if you compile - there will be error. So, from my point of view, deprecation to error level is breaking change. Therefore, semantic versioning requires increase major version number. I would prefer to use deprecation with warning level and increase minor version number. And after some time increase major version with removal deprecated API.

@Mikhail Thank you for your interesting point of view on this subject. Working this way seems to be simpler than using multiple levels of deprecation.

But it could also be a compatible change because it doesn't change the ABI of the package...

That doesn't seem like a compelling argument to me.

What do you mean @Jacob?

The concept of api in regards to semver has little to do with the abi of the package

The concept of api in regards to semver has little to do with the abi of the package

@Jacob Does it mean that introducing an incompatible binary change being source compatible should be done in a major release following the Semantic Versioning specifications ? For example, adding an optional parameter to a function is an incompatible binary change but doesn't break the consumer's source.

I agree with this answer https://github.com/semver/semver/issues/590#issuecomment-656883947

If my understanding of this answer is correct @Jacob, it means that the maintainer is free to define what public component is subject to Semantic Versioning. For example, the stable's source and binary API could be subject to Semantic Versioning, and the experimental's source and binary API can be subject to another versioning strategy.

We do not create a library, but a SaaS app. After someone used @Deprecation annotations in our code we decided this is not for us, as we do not publish a library. If you want to change how something is done/used, just change it all in one PR: no need to deprecate.

It depends on the type of product that you are shipping, It depends on the type of product that you are shipping, but @Cies your workflow is adapted to yours. I didn't precise it in my question, by it was most for libraries than for Software as a Service applications... But thank you for taking time to answer this question with a different point of view.