Bundler 1.16.5 repairs patch-update preferences
Bundler 1.16.5 prefers stable versions during patch updates and handles a compact-index range failure. Its maintenance fixes concern both choosing dependencies and retrieving the metadata used to choose them.
Asking for a patch update expresses more than a desire for the largest available version. It indicates a preference for a limited change within an existing dependency set. Bundler 1.16.5 corrects the handling of prerelease candidates during that operation and repairs failures in obtaining dependency metadata.
The RubyGems version record dates the release to September 18. Its tagged changelog names a preference for non-prerelease versions during patch updates, handling of RangeNotSatisfiable in the compact index and a LoadError correction for nested bundle exec calls.
I find Ruby readable enough that dependency mechanics can become a disproportionate part of maintaining a small program. A patch update should express its intended policy clearly. This release is useful because the corrected behavior concerns the tool interpreting that request.
A preference differs from a hard version limit
The GemVersionPromoter implementation orders available versions before the resolver chooses a compatible set. Its comments distinguish the ordinary preference from strict mode. Without strict mode, versions outside the requested level remain available when dependency requirements need them.
That means patch preference is not by itself an absolute prohibition on considering another version level. Strict mode filters candidates outside the permitted range. The distinction matters when explaining why a dependency resolver can choose something other than the user's first preference.
For a patch-level strict filter, the implementation compares the major and minor segments against the locked version and excludes older versions. The non-strict path instead sorts the candidates. The resolver still has to satisfy the bundle's dependency requirements.
The 1.16.5 correction makes prerelease status part of that ordering when a prerelease was not explicitly requested. The comparator distinguishes a prerelease candidate from a stable candidate before applying the remaining version-order logic.
This preserves an important interpretation of a conservative update request. A prerelease should not become preferable merely because another part of the ordering favors its numeric segments. Explicit prerelease intent remains relevant through the promoter's recorded setting.
The command affected by the changelog entry is the ordinary patch-update request.
bundle update --patch
Its outcome still depends on the available versions and dependency constraints. The release changes preference behavior within that process, rather than promising one fixed result for every Gemfile.
Metadata retrieval can fail before resolution begins
The compact-index correction concerns HTTP range requests. The tagged updater attempts to retrieve new bytes when it already has a local metadata file. It supplies an entity tag and a Range header based on the current file size.
For a nonempty file, it starts the requested range one byte before the end of the local file. A source comment explains that subtracting the byte avoids an empty range and a 416 Range Not Satisfiable response. When the server returns partial content, the updater skips the overlapping byte before appending the rest.
This is a small protocol adjustment with a clear purpose. Incremental retrieval needs to handle a remote file that has no additional bytes in the expected form. Requesting overlap gives the client a nonempty range while its append logic accounts for that overlap.
The updater also checks the resulting file against the response's entity tag. If the check fails, it retries without using the existing local file. A repeated mismatch produces a specific checksum error. Incremental transfer is therefore paired with a check of the assembled metadata.
The update is prepared through a temporary file and moved to the local destination only after the check succeeds. That separates constructing a candidate metadata file from accepting it as the cached result. The patch-release topic includes this transfer behavior because the resolver depends on metadata it can read successfully.
Execution and implementation compatibility also improve
The changelog fixes a LoadError in nested bundle exec calls. That is distinct from selecting gem versions. A process can have a valid dependency set and still fail while establishing the execution environment for another bundled command.
Bundler 1.16.5 also adds TruffleRuby support and avoids certain git errors when checking the version of an incorrectly packaged Bundler. These entries concern the environments in which the tool runs. They do not imply a change to an application's own dependency requirements.
My preference is to separate those failure stages when diagnosing a dependency problem. An HTTP range error occurs while retrieving metadata, a resolver preference influences version choice, and a nested execution error occurs when launching work under the bundle. Their shared symptom may be a failed command, but their mechanisms differ.
This maintenance release addresses each stage through its own correction. Stable versions receive the intended preference during patch updates. Compact-index retrieval handles the end-of-file range case through an overlapping request, and nested bundle execution receives its LoadError fix.