docs: document release candidates, patch releases, and continuous builds - #9230
Vaivaswat2244 wants to merge 3 commits into
Conversation
|
|
||
| ### Release candidates | ||
|
|
||
| Minor and major releases get one or more release candidates (RCs) before the final version. RC versions use the format `x.y.z-rc.N` and are released like a regular release, by pushing a tag such as `v2.4.0-rc.1`. The suffix is `-rc` rather than `-beta` to avoid confusion with [beta.p5js.org](https://beta.p5js.org), the p5.js 2.x site. |
There was a problem hiding this comment.
also: at least one RC is available for testing for at least a week, and if no major regressions are found in that time, then it is released. When major bugs are found a new RC is made available and the clock "Resets." Documentation and small adjustments don't reset the clock. We publish invitations to test on social media (newsletter, Instagram, and Discord) and include instructions for testing in the release notes. All users are welcome to contribute by testing!
(or something like that, please feel free to adjust phrasing)
There was a problem hiding this comment.
Got it! Made changes
| ### Patch releases | ||
|
|
||
| From 2.3.2 onwards, patch releases ship directly, without a release candidate. They are made from the [`stable`](https://github.com/processing/p5.js/tree/stable) branch: isolated or critical fixes are collected with the [`Patch` label](https://github.com/processing/p5.js/issues?q=label%3APatch) and either target `stable` directly or are cherry-picked into it by a maintainer. | ||
|
|
There was a problem hiding this comment.
Would be good to add context that this is because we want tokeep patch releases small and focused on critical or well-isolated fixes, making it possible to roll out a fix more quickly when needed even when there is larger work going on for the upcomign minor release.
There was a problem hiding this comment.
@ksen0 Just to confirm is the intention for the Patch tag to be added by maintainers only? We probably don't want people to automatically add the tag whenever they open a PR.
There was a problem hiding this comment.
@limzykenneth only maintainers and stewards can add labels so I think it's alright? And when releasing the patch I would still manually go through all the htings that are filtered.
I thought it would be nice to inlcude the bit about the label, as it communicates about issue status (when to expect fix to be live, for example) but if you think it's too confusing, its alright to exclude
Maybe it's good to describe that some how, what do you think @Vaivaswat2244 ?
There was a problem hiding this comment.
I think its worth keeping. I can add a line that that the label is applied by maintainers and stewards during triage, so contributors don't need to add it themselves. @limzykenneth does that address it?
|
Thanks for the review! I also noticed the continuous release bot posts a CDN link (raw.esm.sh) alongside the pkg.pr.new package, so I added a script tag example to the Continuous builds section. That makes it possible to test a PR build directly in a browser sketch without npm. |
Adds a section to
contributor_docs/release_process.mdcovering release candidates, the patch release flow fromstable, and pkg.pr.new continuous builds, so testers can find pre-release builds without reading the workflow files.Related to #7934.
Changes:
x.y.z-rc.Nversion format, available vianpm install p5@betaand as GitHub pre-releases with built files attached, and why the suffix is-rcrather than-betastablebranch using thePatchlabelmainorstableis published to pkg.pr.new, with the install URL formatrelease.ymlno longer exists, the workflow is now split intorelease-workflow-v1.ymlandrelease-workflow-v2.yml@ksen0 could you check the wording on the RC and patch release parts?
PR Checklist
npm run lintpasses