What's New in each Release

Add the doctor command for automated troubleshooting. So far, it can automatically detect gems that have been compiled against libraries that no longer exist, and compile them again to fix them. (Thanks @mistydemeo!)

Gems that declare a required_ruby_version will now resolve correctly as long as your Gemfile contains a ruby declaration. If a gem cannot be resolved because of your Ruby version, the error will correctly indicate that your Ruby version conflicts with your other gem version requirements.

In the past, the only way to resolve your Gemfile on a new platform (like java or mswin) was to run bundle install on that platform. We've added explicit options to the lock command to allow managing platforms. Platforms can be added using bundle lock --add-platform NAME, and platforms can be removed using bundle lock --remove-platform NAME.

The update command now has several options to enable users to fine-tune exactly what it is that they will get, using the new flags --major, --minor, --patch, and --strict. It was also recently pointed out to us that running update could even result in some locked gems being changed to an older version! We can’t change the default behavior to avoid that until version 2.0, but for now we’ve added a config setting. To prevent the update command from ever “upgrading” you to an older version, run bundle config only_update_to_newer_versions true.

The plugin system also supports "source" plugins, which means it should be possible to use gems from Subversion, Mercurial, S3, or anything else you can think of. In addition to source plugins, we've started adding new "lifecycle" hooks. That means plugins will be able to hook in and run their own code before, during, or after the install or update process.

automatically trampoline to the bundler version locked in the lockfile, only updating to the running version on bundle update --bundler (@segiddins)