Hello, hope everyone is doing good.
I have a quest...
# serverl
Loïc Lamarque
10/28/2023, 9:30 AMHello, 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 PMIt 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 AMBut 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 PMWhat do you mean @Jacob?
j
Jacob
10/29/2023, 12:50 PMThe 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 PMThe 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 PMI agree with this answer https://github.com/semver/semver/issues/590#issuecomment-656883947
l
Loïc Lamarque
10/29/2023, 2:28 PMIf 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 AMWe 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.
Cies
10/30/2023, 11:59 AMWe 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 PMIt 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
3 Views