docs(changelog): record #9 in the 0.10.0 release notes - #11
Closed
thedumbtechguy wants to merge 2 commits into
Closed
docs(changelog): record #9 in the 0.10.0 release notes#11thedumbtechguy wants to merge 2 commits into
thedumbtechguy wants to merge 2 commits into
Conversation
) * chore(deps): state the Ruby floor, and watch unreleased Rails required_ruby_version claimed ">= 2.3.0", which nothing here could honour: CI exercises 3.0 to 3.3, and activesupport 8 requires Ruby 3.2. A user on an older Ruby got a resolution failure that named none of that. It now says ">= 3.0", matching what is actually tested. No upper bound is needed on activesupport for that to hold - Bundler resolves a version suiting the running Ruby, so a Ruby 3.0 application lands on Rails 7.x by itself. The activesupport and actionpack dependencies stay unbounded above, and RubyGems' warning about that is now overridden knowingly rather than overlooked. A "< N" cap does not protect this gem from the next major; it decides where the breakage surfaces. Capping blocks every downstream application the day that major ships, until this gem cuts a release - a cost everyone pays for a break that may never come. Leaving it open moves that risk from install time to runtime, which is only defensible if someone is watching. The rails-main CI job is that watch: it resolves against rails/rails main and runs the suite, so an incompatible change is found while still unreleased rather than in a bug report the week it lands. It is allowed to fail, because a red run there is a prompt to look rather than a broken build. Its lockfile is gitignored deliberately. Committing one would pin the job to a revision and it would stop watching anything. * fix(ci): give the rails-main job the dev dependencies it runs on The job failed on its first run, and not for the reason it exists to report: `LoadError: cannot load such file -- standard/rake`. The gemfile listed only `gemspec`, which brings the runtime dependencies, so rake, minitest, standard and webmock were all absent and the suite could not load its own Rakefile. It evaluates the root Gemfile now, so the development dependencies come with it and only the Rails version is overridden. Verified locally that the evaluated gemfile does expose standard, minitest, rake and webmock. Also moves the job to Ruby 3.4. Rails main already requires >= 3.3 through ractor-dispatch, which is a genuine finding from that first run, and that floor keeps rising - pinning this job to the minimum would fail it for a Ruby version rather than for the API change it is watching for.
#9 was squash-merged with a non-conventional title, so git-cliff skipped it: the largest change in the release - Messenger, Instagram, the choice resolution rework and the delivery instrumentation fixes - was absent from both CHANGELOG.md and the published GitHub Release, while every other PR in the release appeared. Added by hand, along with the two behaviour changes that reach existing users on upgrade and had no entry anywhere: Intercom now resolving numbers only, and HTTP matching replies exactly. A note marks the section as hand-edited, since regenerating this file will not reproduce those lines. The published release notes have been corrected to match.
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#9 was squash-merged with a non-conventional title, so git-cliff skipped it when v0.10.0's notes were generated.
The effect: the largest change in the release — Messenger and Instagram gateways, the choice-resolution rework, the delivery-instrumentation fixes — appeared in neither
CHANGELOG.mdnor the published GitHub Release, while every other PR in the release (#3 through #8) was listed. Anyone reading the notes to decide whether to upgrade saw an incomplete release.This adds it by hand, plus the two behaviour changes that reach existing users on upgrade and had no entry anywhere:
A note marks the section as hand-edited, because regenerating the file will not reproduce those lines.
The published release notes for v0.10.0 have already been corrected to match, so the tag and the repo agree.
Preventing the recurrence
The root cause is that squash-merging makes the PR title the commit message, so a non-conventional title silently drops the change from the changelog. Nothing enforces the format today. Two options, neither in this PR:
semantic-pull-request-style CI check that fails a PR whose title is not conventional.The first is the more reliable of the two.