Timeline for Refactoring the application with correct SemVer approach
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 5, 2024 at 9:57 | comment | added | Kromster | Would be nice to support that with a link to semver.org | |
| Aug 1, 2024 at 5:20 | comment | added | Rafael | As I noted in my question the behavior of the application and public API remain the same. There are no breaking changes at all. From end-user's perspective it will be the same app, but internally I will refactor all deprecated calls to external dependencies. | |
| Jul 31, 2024 at 20:26 | comment | added | Philip Kendall | I don't disagree with your analysis. I'll leave this answer up for now pending clarification from the querent. | |
| Jul 31, 2024 at 19:20 | comment | added | Thomas Owens♦ | I'm not sure that this answer answers the question. I think the "deprecated calls" are calls to internal libraries or dependencies being removed. Although maybe the wording is confusing, I don't see how you could deprecate and then later remove part of the interface while "maintaining the same ... API". If you had a particular API call that was part of your public interface, removing it would no longer be maintaining the same API, which would make this correct and the question worded wrongly. | |
| Jul 31, 2024 at 19:08 | history | answered | Philip Kendall | CC BY-SA 4.0 |