Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Bundler not finding Contour 1.1.2.pre Prerelease Gem on bundle update #2209

remomueller opened this Issue · 12 comments

3 participants


I'm the owner of the Contour gem, and pushed a new prerelease version 1.1.2.pre to RubyGems. I've done prerelease versions in the past, and have always been able to specify the version then in the Gemfile, for example: gem 'contour', '~> 1.1.2.pre'. Then followed by a bundle update, the gem would install correctly.

For some unknown reason, bundler is unable to find this gem, although it is available on RubyGems:

I've also opened an issue on RubyGems Help in case it is actually a RubyGems error.

TL;DR Pushed a prerelease gem and Bundler has no knowledge of it.


Didn't work, I pushed the gem on December 5th, thinking it would have updated the index by now. Also noted that it never shows up in the dependencies JSON file that Bundler checks dependencies against (although prior prerelease gems do show up in the list):


Looks like this is more of a potential issue with RubyGems versioning and my understanding of Semantic Versioning.

It looks like prerelease is only recognized by RubyGems when the minor number is bumped major.minor.patch-build.


1.0.0  =>  1.1.0.pre

What apparently fails is:

1.0.0  =>  1.0.1.pre

So I guess it's my fault for wanting to do a prerelease on a patch level version.

Closing, as I don't think this is a Bundler issue.

Time to yank the gem, and put it on a new branch. Thanks.


@remomueller you may just be having an issue with rubygems version constraints — Rubygems counts 1.0.1.pre as "less" than 1.0.1, but greater than 1.0.0. Here's an example:

1.9.3-p327 :004 >"~> 1.0.1.pre").satisfied_by?("1.0.1.pre"))                   
 => true 
1.9.3-p327 :005 >"~> 1.0.1").satisfied_by?("1.0.1.pre"))                       
 => false 
1.9.3-p327 :006 >"~> 1.0.0").satisfied_by?("1.0.1.pre"))
 => true 

Hmm thanks @indirect that's how I understood it too. (I didn't know about the Gem::Requirement functionality).

This release is intentionally between 1.1.1 < 1.1.2.pre < 1.1.2, however it seems RubyGems doesn't actually even consider placing branch level pre-releases in the API dependency list

I released a version 1.1.1 recently, and wanted to have a new pre-release of a patch-level branch (so 1.1.2.pre), so that Gems bundled using gem 'contour', '~> 1.1.1' would not be accidentally bumped to the new pre-release on a bundle update without explicitly stating gem 'contour', '~> 1.1.2.pre' in the Gemfile.

I did a patch-level release since I intend to have 1.1.2 fully backwards compatible with projects dependent on 1.1.1 or higher, however in order to test bugs that may arise I did the pre release.

It may be better to continue the discussion on the RubyGems ticket I've opened as it may be more applicable there as opposed to bundler:

Thanks for the input!


UPDATE: I now realize why RubyGems returns the API as it currently does.

As @indirect stated, Gem requirements are satisfied by the Gem number specified in the Gemfile.

Specifying ~> 1.1.1 will update on the patch ignoring patch level pre-releases as seen below."~> 1.1.1").satisfied_by?("1.1.2.pre"))
 => true

This wouldn't be what is expected which is probably why RubyGems doesn't add patch-level pre-releases to their API.

On the other hand, as expected, a minor bump wouldn't satisfy the Gem dependency."~> 1.1.1").satisfied_by?("1.2.0.pre"))
 => false 

Regardless, closing the issue on RubyGems also, and will go with a new version branch to avoid these complexities.


@remomueller ah, I also failed to explain one additional quirk of the way prereleases work in Gemfiles. In order to get a prerelease gem via bundler, your version requirement must be a prerelease. Let's say you have released gem foo with versions 1.0.1 and 1.0.2.pre. Here is how to write a Gemfile to get those gems:

gem 'foo', '~> 1.0.0' #=> installs 1.0.1
gem 'foo', '~> 1.0.0.pre' #=> installs 1.0.2.pre

The requirement must contain some alphanumeric characters as a way to indicate to Bundler that prererelease gems are allowed to be searched for. HTH.


That's the part I don't quite understand, I do have it specified in a prerelease format:

gem 'contour', '~> 1.1.2.pre'

After which I get failures on Travis-CI:

$ bundle install
Fetching gem metadata from
Fetching gem metadata from
Could not find gem 'contour (~> 1.1.2.pre) ruby' in the gems available on this machine.

The strange part is I can install the gem using

gem install contour -v1.1.2.pre


gem install contour --pre

That part is a bug in rubygems/bundler-api :( We're hoping to have it fixed today.


Ah, great, thanks! I'll be happy to try it out when the fix is available. Thanks for all the help!


The fix is rolled out. Sorry about that!


Awesome, just gave it a try and it works well, thank you!

$ bundle update
Fetching gem metadata from
Fetching gem metadata from
Using rake (10.0.2) 
Using rails (3.2.9) 
Installing contour (1.1.2.pre2) 
Using mysql2 (0.3.11) 
Using uglifier (1.3.0) 

Your bundle is updated! Use `bundle show [gemname]` to see where a bundled gem is installed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.