docs(maintaining): add release manager rotation
This commit is contained in:
parent
eb82054357
commit
12b1e484be
1
.github/ISSUE_TEMPLATE/release.md
vendored
1
.github/ISSUE_TEMPLATE/release.md
vendored
@ -9,6 +9,7 @@ assignees: "@cdr/code-server-reviewers"
|
|||||||
<!-- Maintainer: fill out the checklist -->
|
<!-- Maintainer: fill out the checklist -->
|
||||||
|
|
||||||
## Checklist
|
## Checklist
|
||||||
|
|
||||||
- [ ] Assign to next release manager
|
- [ ] Assign to next release manager
|
||||||
- [ ] Close previous release milestone
|
- [ ] Close previous release milestone
|
||||||
- [ ] Create next release milestone
|
- [ ] Create next release milestone
|
||||||
|
@ -10,7 +10,7 @@ TODO
|
|||||||
|
|
||||||
Follow "Publishing a release" steps in `ci/README.md`
|
Follow "Publishing a release" steps in `ci/README.md`
|
||||||
|
|
||||||
<!-- Note some of these steps below are redudant since they're listed in the "Publishing a release" docs -->
|
<!-- Note some of these steps below are redundant since they're listed in the "Publishing a release" docs -->
|
||||||
|
|
||||||
- [ ] double-check github release tag is the commit with artifacts (_note gets messed up after uploading assets_)
|
- [ ] double-check github release tag is the commit with artifacts (_note gets messed up after uploading assets_)
|
||||||
- [ ] publish release and merge PR
|
- [ ] publish release and merge PR
|
||||||
|
@ -72,6 +72,7 @@ VS Code v1.56
|
|||||||
- docs(maintaining): add merge strategies section #3379 @jsjoeio
|
- docs(maintaining): add merge strategies section #3379 @jsjoeio
|
||||||
- refactor: move default PR template #3375 @jsjoeio
|
- refactor: move default PR template #3375 @jsjoeio
|
||||||
- docs(contributing): add commits section #3377 @jsjoeio
|
- docs(contributing): add commits section #3377 @jsjoeio
|
||||||
|
- docs(maintaining): add process for release managers #3360 @jsjoeio
|
||||||
|
|
||||||
### Development
|
### Development
|
||||||
|
|
||||||
|
@ -10,6 +10,8 @@
|
|||||||
- [Versioning](#versioning)
|
- [Versioning](#versioning)
|
||||||
- [Pull Requests](#pull-requests)
|
- [Pull Requests](#pull-requests)
|
||||||
- [Merge Strategies](#merge-strategies)
|
- [Merge Strategies](#merge-strategies)
|
||||||
|
- [Release](#release)
|
||||||
|
- [Release Manager Rotation](#release-manager-rotation)
|
||||||
|
|
||||||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||||||
|
|
||||||
@ -75,3 +77,16 @@ If a PR does fix an issue, don't add it to the version milestone. Otherwise, the
|
|||||||
### Merge Strategies
|
### Merge Strategies
|
||||||
|
|
||||||
For most things, we recommend "Squash and Merge". If you're updating `lib/vscode`, we suggest using the "Rebase and Merge" strategy. There may be times where "Create a merge commit" makes sense as well. Use your best judgement. If you're unsure, you can always discuss in the PR with the team.
|
For most things, we recommend "Squash and Merge". If you're updating `lib/vscode`, we suggest using the "Rebase and Merge" strategy. There may be times where "Create a merge commit" makes sense as well. Use your best judgement. If you're unsure, you can always discuss in the PR with the team.
|
||||||
|
The code-server project follows traditional [semantic versioning](ttps://semver.org/), with the objective of minimizing major changes that break backward compatibility. We increment the patch level for all releases, except when the upstream Visual Studio Code project increments its minor version or we change the plugin API in a backward-compatible manner. In those cases, we increment the minor version rather than the patch level.
|
||||||
|
|
||||||
|
## Release
|
||||||
|
|
||||||
|
### Release Manager Rotation
|
||||||
|
|
||||||
|
With each release, we rotate the role of "release manager" to ensure every maintainer goes through the process. This helps us keep documentation up-to-date and encourages us to continually review and improve the flow with each set of eyes.
|
||||||
|
|
||||||
|
If you're the current release manager, follow these steps:
|
||||||
|
|
||||||
|
1. Create a [release issue](../.github/ISSUE_TEMPLATE/release.md)
|
||||||
|
2. Fill out checklist
|
||||||
|
3. After release is published, close release milestone
|
||||||
|
Reference in New Issue
Block a user