jmettraux/rufus-scheduler

Please use Semantic Versioning (SemVer)

Closed this issue ยท 2 comments

veganstraightedge commented

Hi. First off, we use rufus-scheduler at work and it improves our work. Thank you for making it! ๐Ÿ‘๐Ÿป

We also use @dependabot to get automatic version bumps of our dependencies in our Gemfile.

Dependabot recently created a PR to bump us from 3.4.2 to 3.5.2.

Bump rufus-scheduler from 3.4.2 to 3.5.2

This broke dozens of our tests when CI ran.

The reasons for broken tests were:

  • NameError: uninitialized constant Rufus::Scheduler::CronLine
  • NoMethodError: undefined method days' for #Fugit::Cron:0x000055ab53132ed8`

It looks like this commit made API compatibility breaking changes:
5fad18c

When breaking API compatibility like this, it really helps downstream users (like us) if you do one or some of these things:

  • Replace the underlying dependency, but keep the surface level API (ie, keep Rufus::Scheduler::CronLine in place and call out to Fugit::Cron)
  • Provide a minor version (3.x) release with a deprecation warning with a migration path (ie, change Rufus::Scheduler::CronLine to Fugit::Cron)
  • Release a major version (4.0) with the breaking changes.

That way we're give some signal that there might be / definitely are breaking changes.

Thanks again for making rufus-scheduler. ๐Ÿ‘๐Ÿป

jmettraux commented

Sorry about that.

I didn't think anybody out there was using Rufus::Scheduler::CronLine, I did not consider it a surface level API at all, although, granted, it appeared in a pinch in the README. What I considered the surface level API did not change.

Oh well, when things break you learn about who is using your software and how, and you get schooled and shamed.

Best regards.

veganstraightedge commented

No sweat. Things happen. ยฏ_(ใƒ„)_/ยฏ
Thanks for understanding.