[JohnMcLear]

develop has required linear history, but bin/release.ts ended by merging master back into develop. The push of that merge commit was rejected ("This branch must not contain merge commits", see the 3.3.12 release run), and push-after-release.sh had no set -e, so the job went green with master and the tags pushed but develop still on the old version. That's why develop sat at 3.3.10 after 3.3.11 and at 3.3.11 after 3.3.12, and each next release had to be bumped by hand.

• bin/release.ts: drop the merge-back. develop keeps its own "bump version" commit and is pushed as a fast-forward; the next release's develop→master merge picks it up as before.
• bin/push-after-release.sh: set -euo pipefail and a single git push --atomic for master, develop and both tags, so a rejected ref fails the job and nothing is half-shipped.
• Bump develop to 3.3.12 to match the release that just shipped.

The release bot (etherpad-release-bot) is already a bypass actor for the develop required-checks ruleset, so the fast-forward push is allowed.

Tests: bash -n on the script; simulated the release git steps against a local bare repo (bump on develop, --no-ff merge into master, tags, then the new push script): all four refs pushed and develop has no merge commits.

🤖 Generated with Claude Code

https://claude.ai/code/session_01V4cYEvi9Y4BTPntnkV9tzh

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Prevent release pushes from leaving develop behind

🐞 Bug fix 🕐 20-40 Minutes

AI Description

• Keep develop’s version-bump commit without merging master back into its linear history.
• Push master, develop, and both release tags atomically so a rejected ref fails the push.
• Synchronize package versions to the already-shipped 3.3.12 release.

Diagram

graph TD
  Develop["Develop bump"] --> Master["Master merge"] --> Tags["Release tags"] --> Atomic["Atomic push"] --> Origin["Origin refs"]
  Develop --> Atomic
  Docs["Docs commit"] --> DocsPush["Separate docs push"]

Loading

High-Level Assessment

Keep the proposed approach: omitting the merge-back preserves develop’s required linear history, and an atomic push prevents partial publication of the Etherpad refs. Rebasing or cherry-picking master back onto develop would add unnecessary history manipulation. The documentation repository remains outside that atomic transaction because it is pushed separately.

Files changed (6) +10 / -8

Bug fix (2) +6 / -4

push-after-release.shFail on errors and atomically push release refs +4/-2

Fail on errors and atomically push release refs

• Enables strict shell error handling and replaces separate branch and tag pushes with one atomic push of master, develop, and both version tags. The sibling documentation repository is still pushed separately.

bin/push-after-release.sh

release.tsLeave develop on its linear version-bump commit +2/-2

Leave develop on its linear version-bump commit

• Removes the final master-to-develop merge, whose merge commit could be rejected by develop’s linear-history rule. The release still merges develop into master and creates both tags.

bin/release.ts

Other (4) +4 / -4

package.jsonSet admin package version to 3.3.12 +1/-1

Set admin package version to 3.3.12

• Synchronizes the admin package version with the release already shipped.

admin/package.json

package.jsonSet bin package version to 3.3.12 +1/-1

Set bin package version to 3.3.12

• Synchronizes the bin package version with the release already shipped.

bin/package.json

package.jsonSet root package version to 3.3.12 +1/-1

Set root package version to 3.3.12

• Synchronizes the root package version with the release already shipped.

package.json

package.jsonSet source package version to 3.3.12 +1/-1

Set source package version to 3.3.12

• Synchronizes the source package version used by the release push script with the release already shipped.

src/package.json

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗