1

We have a gem which as development dependencies relies on sass-rails (specifically in version 5.0.4) which in turn depends on railties >4.0.0 and <5.0.

Now we don't check our Gemfile.lock into the repo to keep it as flexible as possible (it's our 'universal' gem after all), and during the travis build, installing sass-rails resolves its dependency railties to version 5.0.0.beta1, which I'd say intuitively isn't <5.0 and now causes problems when running the tests on ruby < 2.2.2 (due to rack).

Now, am I misunderstanding something or is this a bug, that bundler installs 5.0.0.beta1 for <5.0?

CMW
  • 3,093
  • 1
  • 16
  • 20
  • Why exactly don't you check in `Gemfile.lock`? AFAIK it's a bad practice – Mike Szyndel Jan 14 '16 at 11:26
  • We don't check it in, since it's a gem anyway and the Gemfile.lock is of no consequence to the version lookup when using the gem in another project. By not checking it in, we are making sure, travis always uses the most recent version of every gem in the gemspec. – CMW Jan 14 '16 at 11:31
  • Ok, sorry. I missed it's a gem in the first read. Then it makes sense, since you can also specify versions in `gemspec` if needed. – Mike Szyndel Jan 14 '16 at 12:33
  • What kind of flexibility does not checking in your `Gemfile.lock` give you? A gem's `Gemfile` and `Gemfile.lock` only describe development dependencies. People who use your gem will only be restrained by the runtime dependencies in your `gemspec`. – Raffael Jan 14 '16 at 20:02
  • @Raffael actually, the gemspec describes the development dependencies, too. With railties locked within Gemfile.lock our CI tests would have run and only subsequently caused other projects to fail that included this gem and would therefore include the latest version of railties as a dependency (since they don't follow Gemfile.lock). So, not putting in a Gemfile.lock makes it easy to catch these things during CI. – CMW Jan 15 '16 at 09:39

1 Answers1

0

This is not a bug but expected behaviour. Prerelease versions are expected to be released before the actual release, hence they are considered smaller.

See http://ruby-doc.org/stdlib-2.0.0/libdoc/rubygems/rdoc/Gem/Version.html for more detail.

You can add a runtime dependency to railties '~> 4.0' to your gemspec to solve this problem.

Raffael
  • 2,639
  • 16
  • 15
  • I was somehow under the assumption that prerelease versions wouldn't be selected at all, unless specifically told so by virtue of exact version number or a --pre modifier on the cmd line. – CMW Jan 15 '16 at 09:24