Bundler 1.14 separates update preference from update limits
Bundler 1.14 adds conservative and patch-level controls for dependency updates. Downloaded gem checksums address a separate question about the package bytes selected by that resolution.
Updating one dependency can also update a library shared with another dependency. That is consistent with resolving a valid graph, but it can expand the change beyond the package named on the command line. Bundler 1.14 adds controls that distinguish the scope of an update from the versions the resolver should prefer.
The 1.14.0 package record dates the stable release to January 20. Its tagged changelog includes conservative update options for both bundle update and bundle lock, alongside validation of gem checksums returned by RubyGems.org. These improvements address different stages of a dependency operation. Resolution chooses versions, while checksum comparison checks the downloaded artifact against the server's expected digest.
I find Ruby approachable for larger object-oriented code, but that readability does not simplify the dependency graph automatically. Update controls help when the intended change is smaller than a complete re-resolution. The useful property is the ability to state that intent in the command instead of inferring it afterward from a large lockfile diff.
A named update can reach shared dependencies
The 1.14 update manual explains the existing behavior with overlapping dependencies. Updating a named gem ordinarily permits its dependencies to update, including a dependency also required by another top-level gem. The second top-level gem can remain at its existing version even while the shared library changes beneath it.
This is why naming a single gem is not the same as limiting the entire operation to one changed entry. Dependency requirements still need a consistent solution, and several packages can depend on the same selected version. An update to one part of that graph can affect the shared selection.
The new --conservative option prevents updating shared dependencies, using the conservative behavior associated with bundle install. The manual contrasts this with the earlier workflow of changing the desired version in the Gemfile and then installing. Bundler 1.14 lets the update command express that restriction directly.
For a project declaring Nokogiri, a targeted conservative operation has this form. It requests an update while retaining the restriction on shared dependencies.
bundle update nokogiri --conservative
The restriction cannot make incompatible requirements compatible. It describes the allowed update, and the resolver still has to find a solution under those conditions. That is useful behavior when the alternative would be quietly broadening the intended dependency change.
Patch preference is not a hard boundary
Bundler 1.14 introduces --patch, --minor and --major as preferences for version selection. The update manual describes each as preferring the corresponding level of update. --major is the default. The additional --strict option changes the interpretation by preventing an update beyond the chosen level.
bundle update nokogiri --patch --strict
This command requests the patch-level restriction as a limit. Without --strict, a patch preference should not be described as a guarantee that no larger version change can occur. The two controls exist because prioritizing candidates and excluding candidates are different resolver operations.
Conservative updating is another independent choice. It concerns shared dependencies, while patch-level options concern version selection. A command that sets one policy does not implicitly establish the other. Understanding those dimensions makes an update invocation more informative than treating every narrow-looking option as an interchangeable request for a small diff.
The distinction also explains a possible resolution failure. A strict limit can exclude a version that would otherwise satisfy the graph after an update. A failed operation then reflects the requested boundary. It does not justify claiming that the resolver should have silently crossed that boundary to complete the update.
Installing and updating have different purposes
The manual recommends bundle install for installing the same exact gems and versions across machines. A lockfile records the selected dependency versions. An unrestricted bundle update ignores those previous selections and resolves the graph again from the Gemfile's requirements and available versions.
That difference gives the new controls their context. They govern a deliberate reconsideration of dependency versions. They do not replace the lockfile's role in recording the selection used by a project. Once an update has selected a graph, the resulting lockfile remains the concrete record to share with other installations.
The release also changes bundle lock so it does not update without --update. That repair keeps an operation on the lockfile from unexpectedly becoming a dependency refresh. It supports the same separation between preserving an existing selection and requesting a new one.
The changelog also improves conflict context when requirements on Ruby or RubyGems prevent resolution. Those requirements belong to the dependency graph as well. Reporting them alongside the conflicting package constraints helps explain why changing an ordinary gem version alone may not produce a valid solution.
Checksums validate a different part of installation
The tagged gem installer computes a SHA256 digest of downloaded gem content and compares it with the expected checksum passed to the installer. A mismatch raises a security error instead of continuing installation. The implementation supports the expected digest's hexadecimal or Base64 representation.
This check establishes agreement between downloaded bytes and the expected digest supplied through the package metadata. It does not establish that the package's code is harmless or that its author is trustworthy. A correctly delivered malicious package can still have a matching digest. Artifact integrity and confidence in the selected dependency require different evidence.
The implementation also returns without comparison when no expected checksum is available or the underlying package source cannot provide the required readable input. The feature should therefore not be described as universal verification of every possible installation source. Its concrete benefit is detecting a mismatch where the expected checksum and readable artifact are available.
I value both improvements because they make separate assumptions explicit. Update options constrain which dependency graph is selected. Checksum validation compares the artifact with the server's recorded bytes. The first reduces unintended version movement, while the second can stop an installation whose downloaded content does not match the expected package.