docs: use exact version tags instead of the moving v1 tag - #116
Conversation
The v1 major tag is frozen at v1.15.0: the voidzero-dev org-level tag ruleset blocks non-fast-forward tag updates, so it can no longer be moved on each release. - Add a Versioning section telling users to pin an exact release tag (or commit SHA) and warning that v1 is frozen and should not be used - Pin all GitHub, GitLab, and Azure examples to v1.16.0 - Pin setup-ref in the GitLab examples to match the remote URL and drop the now-redundant pinned-runtime section - Rewrite the release steps: bump the README tags, no v1 move
The release PR now bumps both the package.json version and the README version tags before the tag is cut.
There was a problem hiding this comment.
Pull request overview
Updates the repository documentation to discourage using the frozen v1 moving tag and instead pin consumers to exact immutable release tags (or SHAs), aligning GitHub Actions / GitLab / Azure usage examples with the current release practices.
Changes:
- Added a new Versioning section explaining exact tag/SHA pinning and warning that
v1is frozen atv1.15.0. - Updated GitHub/GitLab/Azure examples to pin
v1.16.0and aligned GitLabsetup-ref/ AzuresetupRefguidance with the chosen tag. - Bumped
package.jsonversion to1.16.0and updated the release process docs to reflect “bump versions via PR before tagging”.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| README.md | Adds versioning guidance and updates all usage + release documentation to use exact tags rather than v1. |
| package.json | Updates the project version to track the latest release (1.16.0). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (1)
README.md:637
- The release checklist says to confirm only
dist/index.mjsis in sync, but just above it the README states that multiple generated entrypoints underdist/must be committed (dist/index.mjs,dist/gitlab/index.mjs,dist/azure/index.mjs). This mismatch could lead to cutting a release with stale GitLab/Azure runtimes.
2. Update `main` and confirm `dist/index.mjs` is in sync (the working tree must stay clean after building):
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (1)
README.md:637
- The release checklist says to confirm only
dist/index.mjsis in sync, but the build also produces the GitLab and Azure runtimes underdist/(see the “Before Committing” section just above). Calling out onlydist/index.mjsis misleading for release verification; consider referring todist/outputs (or listing the three entry points) instead.
2. Update `main` and confirm `dist/index.mjs` is in sync (the working tree must stay clean after building):
Follow-up to #116 (now merged). An unpinned `setup-ref` (GitLab) or `setupRef` (Azure) downloaded the compiled runtime from the moving `v1` tag, which is now frozen at v1.15.0, so unpinned includes silently ran a stale v1.15.0 runtime. - Default `setup-ref` / `setupRef` (input default and bash env fallback) to `v1.16.0`, the latest release - Update the README input tables and the release checklist: the release PR now also bumps these defaults, so from v1.17.0 on the shipped template downloads the runtime of its own release - Update the `src/azure/template.test.ts` assertion The README examples keep the explicit `setup-ref` pin, which is still the recommended setup and the only correct one for v1.16.0 itself (its shipped template default is the frozen `v1`).
Bump the version to v1.16.1 in package.json, the README examples, and the setup-ref / setupRef defaults in the GitLab and Azure templates. Changes since v1.16.0: - fix: stop defaulting setup-ref/setupRef to the frozen v1 tag (#117) - docs: use exact version tags instead of the moving v1 tag (#116) After merge, tag the merge commit as v1.16.1 and push the tag. --------- Signed-off-by: MK (fengmk2) <fengmk2@gmail.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
The
v1major tag is frozen at v1.15.0: the voidzero-dev org-level tag ruleset blocks non-fast-forward tag updates, so it can no longer be moved on each release. This PR restructures the docs around exact version pinning.Versioningsection: pin an exact release tag (or commit SHA), with a warning thatv1is frozen at v1.15.0 and should not be usedv1.16.0setup-refto the same tag as the remote URL, so the compiled runtime matches the included template; the separate pinned-runtime section is folded into basic usagepackage.jsonversion now tracks the latest release (bumped to 1.16.0); it was pinned at 1.0.0 when releases only moved tagspackage.jsonand the README tags before tagging, nov1moveFollow-up in #117 (stacked on this PR): the GitLab
setup-refand AzuresetupReftemplate defaults still fall back to the frozenv1, so an unpinned include silently gets the v1.15.0 runtime.