Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![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: 9e86989d55
ℹ️ 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".
| /\[!\[Version\]\(https:\/\/img\.shields\.io\/badge\/version-v[^\]]+\]\(https:\/\/github\.com\/zapabob\/codex\/releases\/tag\/v[^)]+\)/, | ||
| `[](https://github.com/zapabob/codex/releases/tag/v${canonicalVersion})`, |
There was a problem hiding this comment.
rust-v tags
The new sync template hard-codes .../releases/tag/v${canonicalVersion}, but the repo’s release pipeline still publishes Rust releases under rust-v* (.github/workflows/rust-release.yml:4-12,35-45), and both installer scripts resolve/download rust-v${version} assets (scripts/install/install.sh:104-126, scripts/install/install.ps1:38-45,67-79). As a result, every future version:sync run will regenerate a README badge link that points at a non-existent release page instead of the actual published artifacts.
Useful? React with 👍 / 👎.
| const changelogArchive = metadata.sync_targets.archives.changelog; | ||
| const releaseArchive = metadata.sync_targets.archives.release_notes; | ||
|
|
||
| const changelog = `# Changelog\n\nCurrent canonical version: **v${canonicalVersion}**.\nCanonical source: \`VERSION\`. Fork/upstream disambiguation lives in \`version-metadata.json\`.\n\n## Current Release — v${canonicalVersion} (${releaseDate})\n\n> This root changelog is the **current release line only**.\n> Legacy v2.x history has been moved to \`${changelogArchive}\` to make the latest release immediately obvious.\n\n### Changed\n\n- Adopted **root \`VERSION\`** as the single canonical version source for release-visible artifacts.\n- Added a machine-readable version metadata file with \`fork_version\` and \`upstream_base\` for fork/upstream conflict resolution.\n- Added generated sync automation for root/package manifests, workspace Cargo version, README display version, release notes, and changelog headers.\n\n### Docs\n\n- Split legacy **v2.x** history from the current **v3.x** release line.\n- Marked the root release notes and changelog as the current release documents.\n- Standardized the displayed release version across README badges and package metadata.\n\n## Historical Release Lines\n\n- **v2.x archive**: \`${changelogArchive}\`\n- **Legacy release notes**: \`${releaseArchive}\`\n`; |
There was a problem hiding this comment.
These generated templates bake in v3.x as the current line and v2.x as the legacy line instead of deriving them from metadata. If the next major release bumps VERSION to 4.0.0, node scripts/sync-version.mjs will still publish a changelog/release-notes set that says the current release line is v3.x, which contradicts the stated goal that future bumps propagate reliably from the canonical version source.
Useful? React with 👍 / 👎.
| Write-Host " 1. node scripts/sync-version.mjs を実行" -ForegroundColor Yellow | ||
| Write-Host " 2. node scripts/sync-version.mjs --check で整合性確認" -ForegroundColor Yellow |
There was a problem hiding this comment.
release_date in the new version-bump workflow
The new recommended flow only tells maintainers to update VERSION and run scripts/sync-version.mjs, but sync-version.mjs renders README/changelog/release notes from version-metadata.json.release_date (scripts/sync-version.mjs:54,107-112). That means the next release will silently keep showing the previous release date unless someone remembers to hand-edit version-metadata.json, so the automated sync path now produces stale release metadata by default.
Useful? React with 👍 / 👎.
|
I have read the CLA Document and I hereby sign the CLA You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot. |
1 participant
Motivation
VERSION) so displayed/manifests/docs stay consistent.fork_version/upstream_base) to disambiguate fork vs upstream and allow automated decision logic.3.xrelease docs immediately obvious while archiving legacy2.xhistory to avoid confusion.Description
VERSIONas the canonical source and addversion-metadata.jsoncontainingfork_version,upstream_base, release lines, and sync targets.scripts/sync-version.mjsto propagate the canonical version intopackage.jsonfiles, the Rust workspace package version (codex-rs/Cargo.toml),README.mdbadge/managed block,CHANGELOG.md, andreleases/RELEASE_NOTES.md, and to provide a--checkmode for validation.releases/legacy/v2.x/CHANGELOG.mdandreleases/legacy/v2.x/RELEASE_NOTES.mdand update root changelog/release-notes to be the current v3 document.version:syncandversion:check), updatescripts/bump-version.ps1to recommend running the sync flow, and bump visible package versions (rootpackage.jsonandpackages/protocol-client/package.json) and the Rust workspace package version to3.0.0to matchVERSION.Testing
node scripts/sync-version.mjs --checkand it returned success (no drift detected).scripts/sync-version.mjswithnode --check scripts/sync-version.mjs(syntax check) and it passed.git diff --checkover modified files to ensure no whitespace/conflict markers and found no issues.VERSION, rootpackage.json,packages/protocol-client/package.json,version-metadata.jsonandcodex-rs/Cargo.tomlall match and it succeeded.Codex Task