https://kotlinlang.org logo
#server
Title
# server
l

Loïc Lamarque

10/28/2023, 9:30 AM
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.
not kotlin but kotlin colored 1
m

Mikhail

10/28/2023, 12:22 PM
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.
l

Loïc Lamarque

10/28/2023, 4:08 PM
@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.
j

Jacob

10/29/2023, 3:47 AM
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.
l

Loïc Lamarque

10/29/2023, 12:37 PM
What do you mean @Jacob?
j

Jacob

10/29/2023, 12:50 PM
The concept of api in regards to semver has little to do with the abi of the package
l

Loïc Lamarque

10/29/2023, 12:58 PM
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.
j

Jacob

10/29/2023, 1:21 PM
l

Loïc Lamarque

10/29/2023, 2:28 PM
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.
c

Cies

10/30/2023, 11:57 AM
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.
We do offer some web services, here we put our deprecation warnings in the API documentation first, then we add logging to deprecated endpoints (or parameters) to find out how often it is still used and by whom (we can then help/pester them to upgrade). Finally we just remove it in a new version.
l

Loïc Lamarque

11/02/2023, 7:11 PM
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.
👍 1