Repository navigation
Drop the Promise That the develop .dev0 Build Sorts Above the Default Release - #1528
Merged
Merged
Conversation
… Release NBGV counts height along the longest path, so a promotion merge puts main one commit ahead of develop's tip, and PEP 440 sorts X.Y.Z.dev0 below X.Y.Z. WORKFLOW.md D3.4 and the section 6 pypi walkthrough promised the develop .dev0 build sorts above the default release, and the pypi-build-default comment rested the same claim on develop's height normally leading. Nothing implements that, so the claim goes from all three. D3.4 and section 6 keep the .dev0 suffix on develop, which PEP 440 already makes a prerelease, and no longer call the build --pre-selectable, which read as a promise that --pre installs it. Refs #1522 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
WORKFLOW.md D3.4 still includes an incorrect Prevents guarantee about renamed/extra branches that does not follow from the described behavior.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
This PR removes an unimplemented documentation promise that develop PyPI .dev0 builds sort above the default release, aligning the written workflow contract and action comments with actual NBGV height and PEP 440 ordering behavior.
Changes:
- Update
WORKFLOW.mdD3.4 and the section 6pypiwalkthrough to drop the “sorts above /--pre-selectable” guarantee while keeping the.dev0suffix ondevelop. - Remove outdated ordering rationale comments from the
pypi-build-defaultcomposite action. - Regenerate the
workflow-ci-contractreference copies/digests and refresh canonical review report entries.
File summaries
| File | Description |
|---|---|
| WORKFLOW.md | Removes the untrue PyPI ordering/--pre promise while keeping the develop .dev0 description. |
| reports/canonical-review.json | Updates unit digests/metadata for the canonical review report after the doc change. |
| .agents/skills/workflow-ci-contract/references/d-guarantees.md | Updates the source skill reference copy of D3.4 to match WORKFLOW.md. |
| .github/skills/workflow-ci-contract/references/d-guarantees.md | Regenerated distributed skill reference copy of D3.4. |
| .github/actions/pypi-build-default/action.yml | Removes outdated comment lines claiming ordering / pip install --pre behavior. |
| .claude-plugin/fleet-skills/skills/workflow-ci-contract/references/d-guarantees.md | Regenerated plugin skill reference copy of D3.4. |
| .claude-plugin/fleet-skills/.source-digests/workflow-ci-contract | Updates the workflow-ci-contract source digest for the plugin distribution. |
Review details
- Files reviewed: 7/7 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
D3.4's Prevents clause said it stops a renamed or extra branch from silently getting a plain version, while its own two-branch literal gives exactly that branch a plain version. What stops it is D2.3's dispatch allowlist, so the clause now names only the non-default leg published as a release. Refs #1522 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Owner
Author
|
Answering Copilot's finding in its review of 2ee1978 on this pull request, #1528 (review), whose thread was resolved before a reply landed.
Fixed in c87b4cd. The clause now reads "Prevents: a non-default leg published as a release." alone. D3.4's two-branch literal gives a renamed or extra branch a plain version, so D3.4 cannot be what stops one, and D2.3's dispatch allowlist in |
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The changes consistently remove an incorrect guarantee from documentation/comments and update the generated artifacts accordingly, with no functional behavior changes introduced.
Review details
- Files reviewed: 7/7 changed files
- Comments generated: 0 new
- Review effort level: Lite
This was referenced Sep 11, 2026
ptr727
added a commit
that referenced
this pull request
Sep 11, 2026
…Hook SemVer2 (#1526) Promotes `develop` to `main`, carrying three merged pull requests. Closes #1521 ## What this promotes - [#1525](#1525) builds the hub `pypi-build-default` PEP 440 version from the `X.Y.Z` core of `SemVer2` instead of NBGV's `AssemblyFileVersion`. For a two-part `version.json` base NBGV fills that fourth segment from the commit id, so a default-branch package never matched the release tag cut beside it. - [#1528](#1528) drops two false statements from `WORKFLOW.md` D3.4 that review of this promotion raised: the promise that the develop `.dev0` build sorts above the default release, which NBGV height does not deliver since a promotion merge puts `main` one commit ahead of `develop`'s tip, and a *Prevents* clause crediting D3.4 with the renamed-branch protection D2.3's dispatch allowlist provides. It settles those two items of #1522. - [#1530](#1530) answers Copilot's finding on this promotion that the version step logged the `branch` input unsanitized. The release task's `validate-release` gate now refuses, before its smoke exit, any branch git would not accept as a name, so no value that reaches a later step can carry a newline and a `::` command or a `##[` token into the job log, and the PyPI version line and the gate's version message stop printing the branch. | #1521 item | Disposition | | --- | --- | | The default stamps `AssemblyFileVersion` (`M.N.P.B`) | Fixed: `SemVer2` with any prerelease or build segment dropped, `.dev0` on `develop` | | The `build-pypi` hook never receives `semver2` | Fixed: both the caller hook and the default receive it, as the `dotnet-publish` and `build-nuget` hooks already do | A value with no `X.Y.Z` core fails the step rather than stamping an empty or four-part version, and the rejected value is printed with every character outside SemVer's own set shown as `?`, so it can form no workflow command. `WORKFLOW.md` "Versioning", D3.4, and the section 6 `pypi` walkthrough state the new source. ## Adopter impact No fleet repository runs the hub default for a release yet, so no published package version changes. A caller `build-pypi` hook keeps receiving `assembly-file-version`, and one that does not declare the new `semver2` input draws only the runner's unexpected-input warning. ## Left open deliberately - [#1522](#1522): D2.2 names `github-release` as a job that does not opt out of the smoke skip, where the build jobs are the ones that do not. Its other two items are settled by #1528. - [#1523](#1523), [#1524](#1524), and [#1527](#1527): older `WORKFLOW.md` statements the tree contradicts, found by whole-unit review of the sections these changes touched and not introduced by them. - [#1529](#1529): the release task's asset-delete step and the documented publisher stubs interpolate the branch into a `run:` script, which crosses no permission boundary. - [#1531](#1531): `WORKFLOW.md` D2 does not yet describe the gate's branch-name refusal. ## Verification Each push ran whole-unit review over the `WORKFLOW.md` sections it touched and a local strict-review pass over the whole diff, then the hosted reviews. - The whole-unit rounds found the defects these changes themselves wrote, all fixed: a strip described as prerelease-only, a section 6 line still naming `AssemblyFileVersion`, a package-matches-tag claim that fails when `SemVer2` carries build metadata, and, once the ordering was dropped, a `--pre`-selectable sentence that read as a promise `pip install --pre` installs the develop build. - The local diff pass on #1525's fix caught that printing the rejected value through `printf %q` still let a legacy `##[` workflow command through, which the runner reads anywhere in a line. The value now prints through SemVer's own character set, and the test pinning that fails against the `%q` version. - Copilot reviewed every head at full coverage. On #1525 its findings were fixed or declined with evidence, on this promotion's first head its three findings were the ordering promise #1528 then dropped, and on #1528 its one finding was the *Prevents* clause, fixed there. - CodeRabbit reviewed #1525 on request, and its one finding was the same ordering promise. - #1530's local review rounds ran past the two-round budget twice, each time with the maintainer's explicit go-ahead. When each fix to one print surfaced the next print of the same unreachable input, the maintainer chose validating the branch once at the gate over sanitizing each print. Copilot's last round there raised one suppressed remark, disproven with git's own refusal of a branch name starting with `-`. - The new release-guard test fails four ways against the unfixed action, the full suite of 1388 tests passes, and the Docker linters, prose gate, spec validation, and generated-skill check are green. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
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
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.
Summary
Settles the ordering item of #1522, which reviewers raised on #1525 and three times on the promotion pull request #1526.
WORKFLOW.mdD3.4 and the section 6pypiwalkthrough promised that the develop.dev0build sorts above the default release, and.github/actions/pypi-build-default/action.ymlrested the same claim on develop's git height normally leading main's. Nothing implements it. NBGV counts height along the longest path, so a promotion merge putsmainone commit ahead ofdevelop's tip, and PEP 440 sortsX.Y.Z.dev0belowX.Y.Z.Constructed example,
"version": "1.2": develop's tip at height 34 builds1.2.34.dev0, promotion releases1.2.35from main, and develop's next commit at height 35 builds1.2.35.dev0, which sorts below1.2.35..dev0suffix ondevelop, which PEP 440 already makes a prerelease. They no longer call the build--pre-selectable either, since with the ordering gone that read as a promise thatpip install --preinstalls it, which holds only while develop's version is the highest published.workflow-ci-contractskill references are regenerated from D3.4.No behavior changes. #1522's remaining item, D2.2's job name, stays open there, and whole-unit review of the edited sections filed what it found in text this change never touched as #1527.
Verification
python3 -m unittest discover -s scripts/tests: 1388 tests OK.scripts/docker_lint.py(7 linters),prose_lint.py --diff origin/develop,spec/validate.py, andbuild_dist.py --checkall pass.🤖 Generated with Claude Code