Use the "dev" tag for new releases #5877
Conversation
|
Reviewer's guide (collapsed on small PRs)Reviewer's GuideImplements a dual npm dist-tag strategy by defaulting new releases to the "dev" tag (instead of "latest"), reserving "latest" for audited versions which are promoted manually. Flow diagram for new release tagging processflowchart TD
A["New release detected"] --> B{"Is prerelease?"}
B -- Yes --> C["Tag as 'next'"]
B -- No --> D{"Is version > latest audited?"}
D -- Yes --> E["Tag as 'dev'"]
D -- No --> F["Tag as patch (manual tag)"]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
1 similar comment
✅ Actions performedReview triggered.
|
WalkthroughThe release workflow changes adjust the dist_tag selection logic: when the local PACKAGE_JSON_VERSION is greater than the latest published version, the tag now resolves to "dev" instead of "latest". The prerelease branch behavior remains returning "next", and the fallback tag for older versions remains "tmp". No other logic or outputs in the script were modified, and there are no changes to exported or public interfaces. Pre-merge checks (2 passed, 1 warning)❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
Tip 👮 Agentic pre-merge checks are now available in preview!Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.
Example: reviews:
pre_merge_checks:
custom_checks:
- name: "Undocumented Breaking Changes"
mode: "warning"
instructions: |
Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).Please share your feedback with us on this Discord post. ✨ Finishing Touches
🧪 Generate unit tests
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
scripts/release/workflow/pack.sh (3)
10-11: Guard against unset PRERELEASE underset -u.If PRERELEASE is not exported by the workflow, this will hard-fail. Safer to default to false.
- if [ "$PRERELEASE" = "true" ]; then + if [ "${PRERELEASE:-false}" = "true" ]; then
7-8: MakeLATEST_NPM_VERSIONresolution resilient (first publish / network hiccups).
npm infocan 404 or transiently fail, which would currently abort the script. Defaulting to 0.0.0 keeps the flow robust.- LATEST_NPM_VERSION="$(npm info "$PACKAGE_JSON_NAME" version)" + LATEST_NPM_VERSION="$(npm info "$PACKAGE_JSON_NAME" version 2>/dev/null || echo 0.0.0)" + LATEST_NPM_VERSION="${LATEST_NPM_VERSION:-0.0.0}"
23-25: Quote$GITHUB_OUTPUTto avoid pathname expansion/whitespace bugs.Minor safety improvement; behavior is otherwise unchanged.
-echo "tarball_name=$TARBALL" >> $GITHUB_OUTPUT -echo "tarball=$(pwd)/$TARBALL" >> $GITHUB_OUTPUT -echo "tag=$(dist_tag)" >> $GITHUB_OUTPUT +echo "tarball_name=$TARBALL" >> "$GITHUB_OUTPUT" +echo "tarball=$(pwd)/$TARBALL" >> "$GITHUB_OUTPUT" +echo "tag=$(dist_tag)" >> "$GITHUB_OUTPUT"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
scripts/release/workflow/pack.sh(1 hunks)
🔇 Additional comments (1)
scripts/release/workflow/pack.sh (1)
12-14: Switching the new-release tag to "dev" matches the stated release policy.This aligns with the PR objective: new publications advance the "dev" tag while "latest" is moved manually upon audit. No functional regressions in this block.
Overview
Use a dual tag:
latest+devAt each point,
devpoints to the latest version (audited or not), whichlatest(which npm serves by default) points to the latest audited version.If the latest version was audited, then both
latestanddevwill point to the same version.How does the users get the package
If a user wants to get the latest audited release:
npm i @openzeppelin/contractsnpm i @openzeppelin/contracts@latestIf a user wants to get the latest release (audited or not):
npm i @openzeppelin/contracts@devIf a user wants to get the latest release candidate (might not exist, might correspond to an unaudited version):
npm i @openzeppelin/contracts@nextChanges to the release process
Summary by Sourcery
Build: