Rails maintenance candidates correct association scope behavior
The second candidates for Rails 5.0.5 and 5.1.3 retain a repair to joins affected by current scope. The 5.1 branch also corrects persistence of children removed before their parent is saved.
A relation can acquire conditions from the context in which it is built, making its resulting query harder to explain from the join call alone. The July Rails maintenance candidates include a repair that prevents Relation#joins from being affected by the target model's current_scope, with an explicit exception for unscoped. This concerns which context contributes to a query, not a new association declaration.
The July 25 announcement publishes Rails 5.0.5.rc2 and 5.1.3.rc2 together. Kasper Timm Hansen asks for regression reports and names July 31 as the expected final release date if none appear. The candidates are available now, while the final date remains conditional.
I find Ruby's readable syntax useful, but an expression can still depend on hidden framework context. Query construction is easier to reason about when the relevant conditions come from defined relations instead of an incidental current scope. A maintenance change that corrects that relationship can matter even when no application-facing method name changes.
The same join repair reaches both release lines
The 5.0 candidate's Active Record changelog and the 5.1 candidate's changelog both record the join change. They credit Sean Griffin and identify issue 29338. The entries appear under the first candidates dated July 19 and remain part of the second candidates.
Both Active Record changelogs say there are no additional changes in their July 25 rc2 sections. That does not mean the complete candidate has no changes relative to the preceding stable version. It means this component has no further entry between its first and second candidates. The comparison baseline is essential when interpreting a short maintenance changelog.
The announcement provides those baselines separately. The 5.0 candidate is compared with 5.0.4, and the 5.1 candidate with 5.1.2. A shared announcement does not make the two version numbers interchangeable. An application on either line needs the candidate for its own branch to exercise that branch's accumulated changes.
The unscoped exception also matters. The changelog does not say all scope-related behavior has disappeared from joins. It identifies a particular unwanted influence while retaining the stated exception. Describing the repair as ignoring every scope would overstate it and could mislead code that deliberately requests unscoped behavior.
Removing an unsaved child must affect later persistence
The 5.1 changelog includes another association repair. When building records through has_many :through, children deleted before the parent was saved could nevertheless be persisted when the parent was saved. The candidate corrects that behavior so those removed children are not subsequently persisted.
The important ordering is within the application's object lifecycle. A child is built through the association, removed before the parent's save, and then the parent is saved. The deletion needs to affect the association's pending persistence state, not merely the immediately visible collection.
This is a concrete example of an in-memory collection and a persistence operation requiring consistent bookkeeping. Seeing that a child is absent before save is insufficient if another part of the association still treats it as pending work. The repair aligns the eventual persistence behavior with the removal already requested by the application.
That entry appears in the 5.1 candidate's changelog and is absent from the corresponding new entries in the 5.0 candidate. It should therefore not be advertised as an identical newly listed repair on both branches. The common release process carries related maintenance work, but the component records remain the evidence for each branch's contents.
I value this specificity because ordinary Ruby collection operations can appear complete before persistence occurs. An association's save path has to honor the earlier operation as well. The candidate gives applications using this lifecycle a versioned repair to compare against their expected behavior.
Candidate feedback needs the exact artifact
The announcement publishes SHA256 values for the component gems in each candidate. These hashes let a maintainer compare a downloaded artifact with the uploaded file. They complement the version identifier when reproducing a report, especially because the two candidate sets contain similarly named components.
A matching checksum establishes which bytes are being tested. It does not establish that the query behavior or association lifecycle is correct for every application. That is the purpose of the regression feedback period, which asks reporters to identify the problem before the planned final builds.
The useful interpretation of rc2 is consequently a specific candidate set with defined branch baselines. Active Record retains the join-scope repair from rc1, and the 5.1 line also retains the correction for removed unsaved children. Those changes can be investigated against the candidate versions now, without treating the expected final release as an event that has already happened.