Does rufus-scheduler follow semver?
Closed this issue · 3 comments
Hi @jmettraux, thanks for all your work on rufus-scheduler and its related projects (EtOrbi, etc)!
I am currently in the process of updating an application using rufus-scheduler 3.2.x to the latest minor release (3.4.x) and have found at least 3 changes that could be considered breaking changes; they caught me off guard and I would expect them to be marked by a major release by semantic versioning.
The simplest example (found in the underlying library, et-orbi) is floraison/et-orbi@5a837bb Although it might have been intended to be private, it's been released as public and then suddenly removed (made private/protected). As the interface has changed, it's considered a breaking change. This change actually hasn't been released yet; I found it on the master branch while finding a different regression in the latest release.
These changes are troubling for consumers of the gem as although not every project uses true semver (for example, Rails), usually there is clear migration documentation or visible deprecation periods. I can't upgrade rufus-scheduler for bug fixes, etc. and feel confident that a regression hasn't occurred (fortunately, our test suite found things rather quickly).
Is rufus-scheduler intended to be using semantic versioning? I just thought I'd ask to make that clear to me, because it would change how I handle these regressions that I'm finding (i.e., I'd treat them as bugs or not, etc.)
Thanks again for all of your work!
Hello,
I'm sorry for the pain. I've been trying to follow loosely semver while gearing up for the upcoming changes (integration of fugit in progress in branch threefive).
I think I should from now on take care to communicate a bit more via the Changelog, and target a 4.x.x for the upcoming rufus-scheduler + fugit release.
Sorry again, people just seem to follow along since 2007 with PRs here and there, complaints on Stack Overflow and the occasional stars. I haven't really had such "roadmap" feedback so far.
I was not aware the changes were so evident. I felt the API stayed the same, even the API at a second degreed (when replacing Time with EtOrbi::EoTime.
If you have further suggestions they are welcome. Thanks for taking the time to share your point of view, letting me wear your shoes.
Best regards
@jmettraux No need to apologize at all!
I just wanted to step in your shoes and ask about your thoughts on breaking changes to have a better understanding of what I should expect, as well as convey some roadmap feedback you say you haven't had much of yet :) My advice would simply be exactly what you already described: communicate potential regressions via the changelog, build a deprecation mechanism to emit warnings of future removals and wait a release to remove them, and/or make large changes only with major versions.
I will gladly be opening some issues and making some patches soon for the specific ones I've found, which I'd just consider at this point to be bugs.
Once again, thanks for your continued work on this project 💙
Thanks a lot!