fix: allow pending minAppVersion floors ahead of a release#3
Conversation
A commit on the default branch may raise manifest.minAppVersion before the release that materializes it into versions.json. The contract previously required strict equality between the current version's recorded floor and the manifest floor, so any floor bump landed on the default branch broke every subsequent Prepare and validate run until hand-edited. Port the pending-floor semantics from PodNotes' local pipeline (its 2.18.4 fix): the manifest floor must equal the recorded floor or increase from it, never fall below it. Tag-state checks stay strict because a tag always materializes its floor. Found by Codex review on chhoumann/PodNotes#289.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fe11121dbe
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| * @param {string} label | ||
| */ | ||
| export function assertPendingMinAppVersion(recorded, manifest, label) { | ||
| if (manifest !== recorded && compareVersions(manifest, recorded) <= 0) { |
There was a problem hiding this comment.
Checked the release-prepare.yml plan job: before it opens the bot PR it only runs release-plan.mjs and release-contract.mjs materialize, not the previous-tag history check. With this predicate, a base where versions.json["2.17.3"] was rewritten from 1.0.0 to 0.9.0 while manifest.minAppVersion stays 1.0.0 is accepted as a pending floor (manifest > recorded), so the generated PR carries the forged history and the pipeline only rejects it after merge in release-validate. Please compare the recorded floor with the current tag/history before accepting recorded < manifest during planning/materialization.
Useful? React with 👍 / 👎.
1 participant
A commit on the default branch may legitimately raise
manifest.minAppVersionbefore the release that materializes the new floor intoversions.json. The v2 contract required strict equality between the current version's recorded floor and the manifest floor, so any floor bump on master broke every subsequent Prepare and validate run until hand-edited.This ports the pending-floor semantics from PodNotes' local pipeline (its 2.18.4 fix - the reference implementation this repo was extracted from): the manifest floor must equal the recorded floor or increase from it, and may never fall below it.
Four sites change:
validateCurrentVersionFiles: pending-aware; still requires the current version to be recordedmaterializeVersionFiles: pending-aware; the new release entry materializes the pending floorvalidateVersionFiles: base root pending-aware; the candidate check stays strict (a release PR always records its floor)release-validate.ymlinline gate: base half pending-aware, release half strictTag-state checks stay strict throughout because a tag always materializes its floor.
Two prior tests encoded the strict behavior; both now assert the real failure modes (missing record, lowered floor). Three new pending-floor regression tests. 46/46 passing.
Found by Codex review on chhoumann/PodNotes#289 - merging that consumer PR without this would regress PodNotes' pending-floor support.