Skip to content

Commit a3663f5

Browse files
authored
Merge pull request #3360 from cdr/jsjoeio/document-release-manager
docs(maintaining): add process for release managers
2 parents 509d91d + 2438fb3 commit a3663f5

File tree

6 files changed

+44
-18
lines changed

6 files changed

+44
-18
lines changed

.github/ISSUE_TEMPLATE/release.md

+16
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
---
2+
name: Release
3+
about: "*For maintainers only*"
4+
title: "release: 0.0.0"
5+
labels: ""
6+
assignees: "@cdr/code-server-reviewers"
7+
---
8+
9+
<!-- Maintainer: fill out the checklist -->
10+
11+
## Checklist
12+
13+
- [ ] Assign to next release manager
14+
- [ ] Close previous release milestone
15+
- [ ] Create next release milestone
16+
- [ ] Associate issue with next release milestone

.github/PULL_REQUEST_TEMPLATE/release_template.md

+5-7
Original file line numberDiff line numberDiff line change
@@ -8,11 +8,9 @@ TODO
88

99
## TODOs
1010

11-
- [ ] test locally
12-
- [ ] upload assets to draft release
13-
- [ ] test one of the release packages locally
14-
- [ ] double-check github release tag is the commit with artifacts (_note gets messed up after uploading assets_)
15-
- [ ] publish release
16-
- [ ] merge PR
17-
- [ ] update the homebrew package
11+
Follow "Publishing a release" steps in `ci/README.md`
12+
13+
<!-- Note some of these steps below are redundant since they're listed in the "Publishing a release" docs -->
14+
15+
- [ ] publish release and merge PR
1816
- [ ] update the AUR package

CHANGELOG.md

+4-3
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@
33
# Changelog
44

55
- [Changelog](#changelog)
6-
- [3.11.0](#3110)
6+
- [Next Version](#next-version)
77
- [New Features](#new-features)
88
- [Bug Fixes](#bug-fixes)
99
- [Documentation](#documentation)
@@ -30,7 +30,7 @@ We copy from here into the release notes.
3030
<!--
3131
Add next version above previous version but below this line using the template
3232
33-
## 0.0.0
33+
## Next Version
3434
3535
VS Code v0.00.0
3636
@@ -52,7 +52,7 @@ VS Code v0.00.0
5252
5353
-->
5454

55-
## 3.11.0
55+
## Next Version
5656

5757
VS Code v1.56
5858

@@ -72,6 +72,7 @@ VS Code v1.56
7272
- docs(maintaining): add merge strategies section #3379 @jsjoeio
7373
- refactor: move default PR template #3375 @jsjoeio
7474
- docs(contributing): add commits section #3377 @jsjoeio
75+
- docs(maintaining): add process for release managers #3360 @jsjoeio
7576

7677
### Development
7778

ci/README.md

+3-7
Original file line numberDiff line numberDiff line change
@@ -24,17 +24,13 @@ Any file or directory in this subdirectory should be documented here.
2424
- It will upload them to the draft release.
2525
6. Run some basic sanity tests on one of the released packages.
2626
- Especially make sure the terminal works fine.
27-
7. Make sure the github release tag is the commit with the artifacts.
28-
8. Publish the release and merge the PR.
27+
7. Publish the release and merge the PR.
2928
1. CI will automatically grab the artifacts and then:
3029
1. Publish the NPM package from `npm-package`.
3130
2. Publish the Docker Hub image from `release-images`.
32-
9. Update the AUR package.
31+
8. Update the AUR package.
3332
- Instructions on updating the AUR package are at [cdr/code-server-aur](https://github.com/cdr/code-server-aur).
34-
10. Wait for the npm package to be published.
35-
11. Update the [homebrew package](https://github.com/Homebrew/homebrew-core/blob/master/Formula/code-server.rb).
36-
1. Install [homebrew](https://brew.sh/)
37-
2. Run `brew bump-formula-pr --version=3.8.1 code-server` and update the version accordingly. This will bump the version and open a PR. Note: this will only work once the version is published on npm.
33+
9. Wait for the npm package to be published.
3834

3935
## dev
4036

ci/build/release-prep.sh

+1-1
Original file line numberDiff line numberDiff line change
@@ -81,7 +81,7 @@ main() {
8181
read -r -p "What version of code-server do you want to update to?"$'\n' CODE_SERVER_VERSION_TO_UPDATE
8282

8383
echo -e "Great! We'll prep a PR for updating to $CODE_SERVER_VERSION_TO_UPDATE\n"
84-
$CMD rg -g '!yarn.lock' -g '!*.svg' --files-with-matches --fixed-strings "${CODE_SERVER_CURRENT_VERSION}" | $CMD xargs sd "$CODE_SERVER_CURRENT_VERSION" "$CODE_SERVER_VERSION_TO_UPDATE"
84+
$CMD rg -g '!yarn.lock' -g '!*.svg' -g '!CHANGELOG.md' --files-with-matches --fixed-strings "${CODE_SERVER_CURRENT_VERSION}" | $CMD xargs sd "$CODE_SERVER_CURRENT_VERSION" "$CODE_SERVER_VERSION_TO_UPDATE"
8585

8686
# Ensure the tests are passing and code coverage is up-to-date
8787
echo -e "Running unit tests and updating code coverage...\n"

docs/MAINTAINING.md

+15
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,8 @@
1010
- [Versioning](#versioning)
1111
- [Pull Requests](#pull-requests)
1212
- [Merge Strategies](#merge-strategies)
13+
- [Release](#release)
14+
- [Release Manager Rotation](#release-manager-rotation)
1315

1416
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
1517

@@ -75,3 +77,16 @@ If a PR does fix an issue, don't add it to the version milestone. Otherwise, the
7577
### Merge Strategies
7678

7779
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.
80+
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.
81+
82+
## Release
83+
84+
### Release Manager Rotation
85+
86+
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.
87+
88+
If you're the current release manager, follow these steps:
89+
90+
1. Create a [release issue](../.github/ISSUE_TEMPLATE/release.md)
91+
2. Fill out checklist
92+
3. After release is published, close release milestone

0 commit comments

Comments
 (0)