Update build and release documentation to include beta text #60035
Conversation
Testing GuidelinesHi @joshuatf @woocommerce/developer-advocacy @woocommerce/flux, Apart from reviewing the code changes, please make sure to review the testing instructions (Guide) and verify that relevant tests (E2E, Unit, Integration, etc.) have been added or updated as needed. Reminder: PR reviewers are required to document testing performed. This includes:
|
📝 WalkthroughWalkthroughThe documentation for the build and publishing process was updated. Changes include adding explicit hyperlinks for pre-checks, introducing a check for GitHub service status, expanding version type options to include "beta," broadening the testing condition to cover both stable and RC releases, refining stable tag updates, and updating pre-release tagging instructions. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~7 minutes Possibly related PRs
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: .coderabbit.yml 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
docs/contribution/releases/building-and-publishing.md (1)
26-27: Tiny wording nit – list the version types in chronological order.Readers mentally map the release flow as beta → rc → stable. Swapping the order matches that mental model:
- - Choose the type of version you're releasing (`beta`, `rc`, or `stable`). + - Choose the type of version you're releasing (`beta`, `rc`, or `stable`).(Only the order inside the parenthesis changes.)
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/contribution/releases/building-and-publishing.md(3 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.856Z
Learning: In WooCommerce core repository, changelog entries for all PRs live in `plugins/woocommerce/changelog/` directory and are processed during releases, not at the repository root level.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-07-21T05:22:46.426Z
Learning: Provide clear, step-by-step instructions for how to test the changes in the PR description.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-07-21T05:22:46.426Z
Learning: Applies to .github/PULL_REQUEST_TEMPLATE.md : The changelog section in the PR description must keep the markdown structure from the PR template exactly as-is, including all checkboxes, comments, and headings. Only the appropriate checkbox may be checked, and the changelog message must be placed under the `#### Comment` heading and before the closing `</details>` tag. Do not add, remove, or reformat any part of the changelog section except for checking the box and adding the message in the correct place.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-07-21T05:22:46.426Z
Learning: Applies to .github/PULL_REQUEST_TEMPLATE.md : Preserve required markdown sections in the PR description, especially those used by automation (e.g., changelog entry details and comments). Do not remove or alter them.
docs/contribution/releases/building-and-publishing.md (11)
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-07-21T05:22:46.426Z
Learning: Provide clear, step-by-step instructions for how to test the changes in the PR description.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-07-21T05:22:46.426Z
Learning: Summarize the changes, testing steps, and rationale in a way that is concise and clear for reviewers.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-07-21T05:22:46.426Z
Learning: Applies to .github/PULL_REQUEST_TEMPLATE.md : Preserve required markdown sections in the PR description, especially those used by automation (e.g., changelog entry details and comments). Do not remove or alter them.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-07-21T05:22:46.426Z
Learning: Applies to .github/PULL_REQUEST_TEMPLATE.md : The changelog section in the PR description must keep the markdown structure from the PR template exactly as-is, including all checkboxes, comments, and headings. Only the appropriate checkbox may be checked, and the changelog message must be placed under the #### Comment heading and before the closing </details> tag. Do not add, remove, or reformat any part of the changelog section except for checking the box and adding the message in the correct place.
Learnt from: jorgeatorres
PR: #59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.856Z
Learning: In WooCommerce core repository, changelog entries for all PRs live in plugins/woocommerce/changelog/ directory and are processed during releases, not at the repository root level.
Learnt from: prettyboymp
PR: #59048
File: .github/workflows/cherry-pick-milestoned-prs.yml:60-83
Timestamp: 2025-06-26T12:45:40.709Z
Learning: WooCommerce uses WordPress versioning conventions where minor versions in X.Y.Z format are constrained to 0-9 (Y cannot exceed 9). This means version increment logic should reset minor to 0 and increment major when minor reaches 9, rather than allowing two-digit minor versions like 9.10 or 9.11.
Learnt from: prettyboymp
PR: #59048
File: .github/workflows/cherry-pick-milestoned-prs.yml:118-131
Timestamp: 2025-07-11T13:05:08.440Z
Learning: In GitHub Actions workflows, when reviewing steps that access event data like github.event.pull_request.milestone, check the entire job dependency chain and conditional logic. If upstream jobs already validate the data exists (like checking github.event.pull_request.milestone != null in a prerequisite job), then downstream jobs don't need redundant null-checks since the data is guaranteed to exist by that point.
Learnt from: jorgeatorres
PR: #59946
File: .github/workflows/release-code-freeze.yml:108-124
Timestamp: 2025-07-23T19:42:10.564Z
Learning: WooCommerce trunk versions follow the pattern X.Y.0-dev where the patch version is always 0. This means when calculating release branches, string operations like slice(0, -2) on the version after removing -dev will always work correctly since the input format is predictable (e.g., 10.2.0 → 10.2).
Learnt from: lysyjan
PR: #59632
File: packages/js/email-editor/src/layouts/flex-email.tsx:116-122
Timestamp: 2025-07-14T10:41:46.200Z
Learning: In WooCommerce projects, formatting suggestions should respect the project's Prettier configuration and linting rules. Changes that would break the lint job should be avoided, even if they appear to improve readability.
Learnt from: opr
PR: woocommerce/woocommerce#0
File: :0-0
Timestamp: 2025-06-20T17:38:16.565Z
Learning: WooCommerce legacy JavaScript files in plugins/woocommerce/client/legacy/js/ must use older JavaScript syntax and cannot use modern features like optional chaining (?.) due to browser compatibility requirements. Explicit null checking with && operators should be used instead.
Learnt from: albarin
PR: #59815
File: .github/workflows/maintenance-update-version-requirements.yml:19-23
Timestamp: 2025-07-23T09:39:44.095Z
Learning: The WordPress SVN repository at https://core.svn.wordpress.org/tags/ only contains stable numeric release versions (like 6.8.2, 6.7.1, etc.) and does not include RC (release candidate), beta, or alpha versions. Therefore, no filtering is needed when fetching the latest WordPress version from this repository.
🔇 Additional comments (1)
docs/contribution/releases/building-and-publishing.md (1)
20-21: Good call-out adding the GitHub status check.Including a quick link to https://www.githubstatus.com/ is a useful safeguard before triggering long-running workflows.
|
Hey folks, are we going back to referring to RC-1 as Beta? |
@piinthecloud, that is what we're currently discussing and planning, likely starting with the 10.2 release cycle. We decided it was better to separate the concept of what we consider a true release candidate vs the initial releases made shortly after code freeze. RCs at this point will be releases that we would otherwise consider stable releases, but are releasing to some internal environments for some final review prior to labeling it as the stable |
Changes proposed in this Pull Request:
This updates the build and release documentation to include the shift from labeling the initial builds after code freeze RCs to beta's.
This reflects the following:
Changelog entry
Doc changes only.
Changelog Entry Details
Significance
Type
Message
Changelog Entry Comment
Comment