search

bkeepers / qu

a Ruby library for queuing and processing background jobs.
MIT License
506 stars 50 forks source link

Qu rails #47

Closed zmoazeni closed 12 years ago

zmoazeni commented 12 years ago

This moves rails code into qu-rails.rb and has a gemspec for it. I bumped the version to v1.0.0. You can change it to something else, but with the deprecation warning in #46 Qu seems to be committing to a public API.

If Qu stays v0.x.x, I wouldn't worry about communicating API changes to the user via deprecation warnings or maintaining backwards compatibility.

bkeepers commented 12 years ago

I'm not ready to go 1.0 yet, but I also want to maintain some sanity in the versioning. Here's what I'd prefer to do for now:

  1. Release 0.1.5 with the qu gem depending on the qu-rails gem.
  2. Update docs to reflect new qu-rails gem.
  3. Keep the conditional check for Rails in qu.rb, require qu-rails, and show deprecation warning about 0.2 needing the separate gem.
  4. Release 0.2.0 with the conditional and dependency on qu-rails removed

Sound reasonable?

zmoazeni commented 12 years ago

I dunno. To lift a quote from http://semver.org/

How do I know when to release 1.0.0? If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users > have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.

You're doing a lot of work for backward compatibility for a v0.x.x library in my opinion. Of course your project == your decision. I would probably handle it with the v1 release or stick with v0.x.x and no deprecation warnings.