-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
187 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,187 @@ | ||
| # Release | ||
|
|
||
| > How we version and release packages in the Design System | ||
| <!-- prettier-ignore-start --> | ||
| <!-- START doctoc generated TOC please keep comment here to allow auto update --> | ||
| <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> | ||
|
|
||
| ## Table of Contents | ||
|
|
||
| - [Overview](#overview) | ||
| - [Release Team](#release-team) | ||
| - [Process](#process) | ||
| - [Prerelease](#prerelease) | ||
| - [Stable release](#stable-release) | ||
| - [Post release](#post-release) | ||
|
|
||
| <!-- END doctoc generated TOC please keep comment here to allow auto update --> | ||
|
|
||
| ## Overview | ||
|
|
||
| The Design System follows a time-based release model where we deliver a stable | ||
| `minor` update every two weeks. The full schedule for releases is available | ||
| [here](https://github.com/carbon-design-system/carbon/wiki/Release-radar). | ||
|
|
||
| We also publish prereleases before every `minor` release. This prerelease | ||
| happens several days before the stable release. This offers an integration | ||
| window where the prerelease can be tested on products before the stable release. | ||
|
|
||
| We also ship security and bug fixes in `patch` releases. This will be shipped | ||
| as-needed and do not follow a specific schedule. | ||
|
|
||
| ## Release Team | ||
|
|
||
| The release team is responsible for coordinating the `minor` and `patch` | ||
| releases for the Design System in a given week. This group is composed of a | ||
| release lead and sidekick. The release lead is responsible for: | ||
|
|
||
| - Managing the release itself, including | ||
| - Testing | ||
| - Publishing | ||
| - Support | ||
| - Helping the release sidekick understand and run through the release process, | ||
| where appropriate | ||
|
|
||
| The release sidekick is responsible for: | ||
|
|
||
| - Learning how to run the release process if this is your first time on the | ||
| release team | ||
| - Helping out the release lead in the release process, this includes helping | ||
| with testing, publishing, support, and more | ||
|
|
||
| ## Process | ||
|
|
||
| When going through a release, the release team will go through the following | ||
| checkpoints: | ||
|
|
||
| | Checkpoint | Description | | ||
| | :------------------------------- | :----------------------------------------------------------------------------------------------------------------------- | | ||
| | [Prerelease](#prerelease) | Publish a prerelease that will be used to test out the release candidate before becoming stabilized | | ||
| | [Stable release](#stablerelease) | Graduate the prerelease into a stable release that is available through packages on NPM | | ||
| | [Post release](#postrelease) | Support the latest stable release and address any issues that may come up as a result of promoting the release to stable | | ||
|
|
||
| ### Prerelease | ||
|
|
||
| The prerelease occurs on the first Tuesday of a sprint. During this stage, the | ||
| release team will need to do the following: | ||
|
|
||
| - [ ] Run the | ||
| [Version Workflow](https://github.com/carbon-design-system/carbon/actions/workflows/version.yml) | ||
| to automatically generate the prerelease versions for packages | ||
| - [ ] Specify `preminor` as the release type | ||
| - [ ] Provide the tag for the release. For example, if the previous release | ||
| was `v11.1.0` this tag would be `v11.2.0-rc.0` | ||
| - [ ] Review and approve the Pull Request generated from this action | ||
| - [ ] When the Pull Request is merged, pull down the latest code from | ||
| `upstream`, tag it, and push it to `upstream` | ||
|
|
||
| ```bash | ||
| git checkout main | ||
| git pull upstream main | ||
| git tag -a v11.2.0-rc.0 -m 'v11.2.0-rc.0' | ||
| git push upstream v11.2.0-rc.0 | ||
| ``` | ||
|
|
||
| - [ ] Verify that this triggers a run of the | ||
| [Release Workflow](https://github.com/carbon-design-system/carbon/actions/workflows/release.yml) | ||
| - [ ] Review and approve the Pull Request generated from this action on the | ||
| [Carbon Website](https://github.com/carbon-design-system/carbon-website) | ||
| to verify no breaking changes have occurred in this release | ||
|
|
||
| ### Stable release | ||
|
|
||
| A stable release occurs on the first Thursday of a sprint and finishes on the | ||
| morning of the first Friday of a sprint. This should occur after the prerelease | ||
| has been tested and validated. During this stage, the release team will do the | ||
| following: | ||
|
|
||
| - [ ] Run the | ||
| [Version Workflow](https://github.com/carbon-design-system/carbon/actions/workflows/version.yml) | ||
| to automatically generate the prerelease versions for packages | ||
| - [ ] Specify `minor` as the release type | ||
| - [ ] Provide the tag for the release. For example, if the previous release | ||
| was `v11.1.0-rc.0` this tag would be `v11.2.0` | ||
| - [ ] Review and approve the Pull Request generated from this action | ||
| - [ ] When the Pull Request is merged, pull down the latest code from | ||
| `upstream`, tag it, and push it to `upstream` | ||
|
|
||
| ```bash | ||
| git checkout main | ||
| git pull upstream main | ||
| git tag -a v11.2.0 -m 'v11.2.0' | ||
| git push upstream v11.2.0 | ||
| ``` | ||
|
|
||
| - [ ] Verify that this triggers a run of the | ||
| [Release Workflow](https://github.com/carbon-design-system/carbon/actions/workflows/release.yml) | ||
| - [ ] Review and approve the Pull Request generated from this action on the | ||
| [Carbon Website](https://github.com/carbon-design-system/carbon-website) | ||
| to verify no breaking changes have occurred in this release | ||
|
|
||
| **Friday** | ||
|
|
||
| The packages that have been published will be switched to latest on the first | ||
| Friday of a sprint. To make the switch, you will need to: | ||
|
|
||
| - [ ] View the last of the | ||
| [Release Workflow](https://github.com/carbon-design-system/carbon/actions/workflows/release.yml) | ||
| which published the packages under the `next` tag | ||
|
|
||
| ``` | ||
| - carbon-components-react => 8.3.0 | ||
| - @carbon/cli => 11.1.0 | ||
| - @carbon/colors => 11.2.0 | ||
| - @carbon/elements => 11.3.0 | ||
| - @carbon/grid => 11.2.0 | ||
| - @carbon/icon-helpers => 10.30.0 | ||
| - @carbon/icons-react => 11.3.0 | ||
| - @carbon/icons => 11.3.0 | ||
| - @carbon/layout => 11.2.0 | ||
| - @carbon/motion => 11.1.0 | ||
| - @carbon/pictograms-react => 11.27.0 | ||
| - @carbon/pictograms => 12.1.0 | ||
| - @carbon/react => 1.3.0 | ||
| - @carbon/styles => 1.3.0 | ||
| - @carbon/themes => 11.3.0 | ||
| - @carbon/type => 11.3.0 | ||
| ``` | ||
|
|
||
| - [ ] Transform this list into a series of `npm dist-tag` commands | ||
|
|
||
| ``` | ||
| npm dist-tag add [email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest && \ | ||
| npm dist-tag add @carbon/[email protected] latest | ||
| ``` | ||
|
|
||
| _Note: this stage is a great candidate for next steps in automation_ | ||
|
|
||
| ### Post release | ||
|
|
||
| After a release has switched packages from `next` to `latest`, it is important | ||
| to monitor channels on Slack and issues on GitHub in case breaking changes may | ||
| have occurred in the release. | ||
|
|
||
| If issues occur for the specific release, it's important to determine the next | ||
| best steps based on the type of issue. Typically, issues fall into one of two | ||
| categories: | ||
|
|
||
| - Hotfix: if the issue is self contained and can be addressed quickly, going | ||
| through a patch release may be the easiest way to resolve the issue | ||
| - Revert to previous stable release: this strategy is helpful if the issue that | ||
| has been identified is not able to be quickly remediated or the timeline is | ||
| unknown |