Gem versioning for multiple environments

BJ Neilsen's Avatar

BJ Neilsen

01 Feb, 2011 08:14 PM

Looking to get some feedback on versioning strategies others have used with gems you've written and use on a project internally. Basically I need the ability to specify gem versions in development (with a patch level), in staging (with an rc identifier), and production (with normal versioning). It would look something like this:

Stable version (in prod): 1.0.0
Unstable version (in dev): 1.0.1-p1
Candidate version (in stage): 1.0.1-rc1
New Stable (after rc's accepted): 1.0.1

So the lifecycle of a gem's version starts at a stable base version. You'd then use a patch-level version for the next version increment on any dev releases of the gem. In this case 1.0.0 is stable and in prod, so the first dev bump is 1.0.1-p1. This could happen any number of times during the development of that specific version. Once you're ready to go to stage (qa) you'd package the latest patch-level dev version into rc1. Similarly, there could be any number of rc bumps to a gem's version (which would probably come through patch versions). Finally when the code has been accepted, the patch-level and rc versions are then removed from the version number, and you're left with just 1.0.1 as the most current stable.

So now that I've described the strategy I'd like to do, the question is... does this make sense from rubygems' perspective? I know that rubygems has some support for beta gems which are basically only available using the --pre option on install or update, but I'm not sure how fully-baked that support is. In either case it seems like it doesn't support multiple non-stable version strategies like I'd hope it would. If I were to use this type of versioning could rubygems actually handle it? What would happen if I asked to install the gem without specifying version. Would it get the most recent stable version (1.0.0) or the most recently sorted alphabetical version (which would probably be the highest patch level ("p" before "r").

The ultimate goal is to always know exactly what code is in your gem in a given environment. Up to this point when changes are made to the gem in development, I'm just overwriting the gem in the index at the version it is at (not the stable, the dev version). Obviously this is not desirable since if I want to update an application to use the overwritten version, I have to manually uninstall and reinstall the gem out on the sandbox. Lame. I should never have to need to overwrite a gem's version.

Any help would be greatly appreciated.

  1. Support Staff 1 Posted by Eric Hodel on 01 Feb, 2011 09:41 PM

    Eric Hodel's Avatar
    $ ruby19 -e 'p %w[1 2.p.1 2.p.2 2.rc.1 2.rc.2 2].map { |v| v }.sort'
    [#<Gem::Version "1">, #<Gem::Version "2.p.1">, #<Gem::Version "2.p.2">, #<Gem::Version "2.rc.1">, #<Gem::Version "2.rc.2">, #<Gem::Version "2">]

    If you wanted only prereleases of the p variety, gem install example --pre -v >= 2.r.0 -v < 2.p should do what you want.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac