[bpamiri]

Summary

Runs tools/changelog-promote.sh 4.2.0 2026-10-11 on develop c3665d9. It assembles the 272 changelog.d fragments into a new # [4.2.0](…) => 2026-10-11 section of CHANGELOG.md (336 entries: Added, Changed, Removed, Performance, Fixed, Security), resets [Unreleased], and leaves changelog.d/ with only its README.

Release-prep PR: it merges as part of the 4.2.0 cut, not before.

• The date is the prep date. If the tag lands on another day, it's a one-line edit to the # [4.2.0] heading.
• A fragment that merges after this promote stays in changelog.d. It would need adding to this section, or re-running the promote, before the tag.

A second commit fills two gaps found while checking PRs merged since 4.1.2 that had no fragment:

• a Fixed line for fix(packaging): accept Java 21 or newer in the .rpm and .deb dependencies #4237 and fix(packaging): launcher finds any Java 21+ under /usr/lib/jvm as a last resort #4243: the Linux packages accept Java 21 or newer, which fixes installing on Fedora 44;
• (#4254) on the framework-suite datasource line, which docs: 4.1 to 4.2 upgrade guide covers the remaining behaviour changes #4295 added for fix(test): keep the framework test runners off an app primary datasource #4254 without a reference.

The other fix/feat/perf PRs without a fragment are build-pipeline fixes, follow-ups to features new in 4.2 (their parent PRs carry the line), or have no behaviour change.

Checks

• changelog-promote.sh --preview and the promote both succeed (they fail loudly on a malformed fragment)
• release.yml's release-notes extraction (awk '/^# \[4\.2\.0\]/,/^---$/') returns the 4.2.0 section only: 357 lines, one version heading, no bleed into 4.1.2
• Bullet text is as the fragments were reviewed; nothing was reworded

🤖 Generated with Claude Code

[bpamiri]

rev1-r3 review @ 4eaf1f4: APPROVE (one wording fix recommended before the cut; see below)

Fragments are all consumed, with nothing lost or duplicated. I compared every changelog.d/*.md at the base (c3665d90e, 272 fragments, 293 top-level bullets) with the new # [4.2.0] section, bullet by bullet, matching both the text and the heading.

• All 293 fragment bullets appear exactly once, under the heading their filename suffix names (added → Added, fixed → Fixed, security → Security, …).
• There are no duplicates and no strays.
• The only differences are the two lines added at 4eaf1f4:
  • the new Fixed line for fix(packaging): accept Java 21 or newer in the .rpm and .deb dependencies #4237/fix(packaging): launcher finds any Java 21+ under /usr/lib/jvm as a last resort #4243 (Java 21+ .rpm/.deb and launcher). I checked it against nfpm-wheels*.yaml (java-21-headless or java-headless >= 1:21; openjdk-21… | openjdk-25…) and the launcher's /usr/lib/jvm search in build-linux-packages.sh.
  • the (#4254) reference appended to the existing core-test-datasource Changed entry.
• changelog.d/ now holds only README.md.

The headings are Added, Changed, Removed, Performance, Fixed and Security, with no empty ones.

Structure:

• ## [Unreleased] is reset to its "write a fragment" comment.
• The new heading matches the previous release's form: # [4.2.0](…/releases/tag/v4.2.0) => 2026-10-11. The date is today's, so set it to the tag date at the cut.

Wording: the section uses no CVE, GHSA, exploit or vulnerability terms. The "advisory" hits in Changed are wheels upgrade check findings, which is fine.

Recommended before the cut: the two heartbeat() entries contradict each other

• Added (feat(job): heartbeat() + heartbeat-aware reaping; idempotent gating of retries after a reap #4477): "…a long job that heartbeats more often than its timeout is no longer reaped and run a second time".
• Fixed (fix(job): let heartbeats shorten dead-worker detection for long jobs #4502): "heartbeat() now shortens how long a dead worker's job goes unnoticed. Before, a job was only reclaimed after twice its timeout whether it heartbeated or not… Heartbeat at least every grace / 3."

Both land in 4.2.0, and heartbeat() didn't exist in 4.1.x. So the Fixed entry describes a "before" no user ever had. Following the Added entry's guidance under the shipped default (300 s grace) gets a job reclaimed: a 1-hour-timeout job heartbeating every 10 minutes stops being protected.

Suggested fix:

1. Rewrite the Added entry's sentence to the shipped rule: reclaimed once heartbeats stop for the grace (jobsHeartbeatGraceSeconds, default 300, or this.heartbeatGrace); heartbeat at least every grace / 3; this.timeout stays the hard cap.
2. Move the fix(job): let heartbeats shorten dead-worker detection for long jobs #4502 entry's grace details into it and drop the Fixed entry. Alternatively, keep it in Changed without the "Before" framing.

PR CI: 12 pass, 3 skipping, 0 fail. Up to date with develop, MERGEABLE.

[bpamiri]

rev1-r3 re-check @ 315e05d: APPROVE

The heartbeat fold resolves the contradiction I flagged. #4477's Added entry and #4502's Fixed entry are now one Added entry, linking both issues. Checked against the code I reviewed in #4507:

• The grace rule is right: this.heartbeatGrace, else jobsHeartbeatGraceSeconds, default 300, 0 off, raised to 30. So is "heartbeat at least every grace / 3".
• The claim window for a job that never heartbeats is right: timeout + max(60 s, timeout).
• this.timeout stays the hard cap, the stuck-perform() caveat is kept, and the rest is unchanged (lease renewal by the grace, Wheels.Job.Fenced, the per-claim reset, the heartbeatAt column).
• "More often than its timeout" and the never-shipped "Before, …" are gone.

Re-ran the fragment-by-fragment comparison against base c3665d90e: 293 fragment bullets map to 293 changelog bullets. The only differences are the intended edits:

• the merged heartbeat entry, which replaces the two fragments;
• the (#4254) reference;
• the Java 21+ Fixed line.

changelog.d/ is still only README.md. develop has moved one commit (#4550, API reference JSON), which adds no fragment and doesn't touch CHANGELOG.md.

PR CI: 12 pass, 3 skipping, 0 fail. Still to do at the cut: set the heading date to the tag date.