CODEWITHSUNDEEP
rubyrubygemsversioning
Andrew Nesbitt
Andrew Nesbitt

Reputation: 6046

What is the best practice for version numbers for ruby gem extensions?

I have a ruby gem (Split) which is at version 0.2.2 and an extension to it as a separate gem (Split::Export) which is loaded in a similar style to rack extensions:

gem 'split-export', :require => 'split/export'

How should I manage the versioning of the extension?

Should it match the major or the minor version of the gem it extends or should it match the patch level exactly, are there any other trends or examples of this with other gems that I can mirror?

Upvotes: 2

Views: 308

Answers (1)

dimitarvp
dimitarvp

Reputation: 2383

Your best bet is:

  1. Start your gem extension version at 0.0.1 as first release.
  2. Make sure you maintain solid test suite so you test your parent gem (in your case "split") maintains the behaviour you depend on. Whatever you do, do not skip this!
  3. Always maintain a documentation saying what version of your parent gem ("split") are you supporting for sure. Example: "split" gem has 1.1.0, 1.1.6, 1.2.1 versions. If the last version you tested is 1.1.6, make a README which says: "split-export" is proven to work with all versions of "split" up to 1.1.6. Use further versions at your own risk. Or something similar.
  4. And of course, needless to say, track the version history of your parent gem and run tests against it periodically.

These are very basic TDD practices, but it never hurts to reiterate them. Hope I helped.

Upvotes: 1

Related Questions