Skip to content

docs(maintaining): add process for release managers #3360

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
May 14, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions .github/ISSUE_TEMPLATE/release.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
---
name: Release
about: "*For maintainers only*"
title: "release: 0.0.0"
labels: ""
assignees: "@cdr/code-server-reviewers"
---

<!-- Maintainer: fill out the checklist -->

## Checklist

- [ ] Assign to next release manager
- [ ] Close previous release milestone
- [ ] Create next release milestone
- [ ] Associate issue with next release milestone
12 changes: 5 additions & 7 deletions .github/PULL_REQUEST_TEMPLATE/release_template.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,11 +8,9 @@ TODO

## TODOs

- [ ] test locally
- [ ] upload assets to draft release
- [ ] test one of the release packages locally
- [ ] double-check github release tag is the commit with artifacts (_note gets messed up after uploading assets_)
- [ ] publish release
- [ ] merge PR
- [ ] update the homebrew package
Follow "Publishing a release" steps in `ci/README.md`

<!-- Note some of these steps below are redundant since they're listed in the "Publishing a release" docs -->

- [ ] publish release and merge PR
- [ ] update the AUR package
7 changes: 4 additions & 3 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
# Changelog

- [Changelog](#changelog)
- [3.11.0](#3110)
- [Next Version](#next-version)
- [New Features](#new-features)
- [Bug Fixes](#bug-fixes)
- [Documentation](#documentation)
Expand All @@ -30,7 +30,7 @@ We copy from here into the release notes.
<!--
Add next version above previous version but below this line using the template

## 0.0.0
## Next Version

VS Code v0.00.0

Expand All @@ -52,7 +52,7 @@ VS Code v0.00.0

-->

## 3.11.0
## Next Version

VS Code v1.56

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

### Development

Expand Down
10 changes: 3 additions & 7 deletions ci/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,17 +24,13 @@ Any file or directory in this subdirectory should be documented here.
- It will upload them to the draft release.
6. Run some basic sanity tests on one of the released packages.
- Especially make sure the terminal works fine.
7. Make sure the github release tag is the commit with the artifacts.
8. Publish the release and merge the PR.
7. Publish the release and merge the PR.
1. CI will automatically grab the artifacts and then:
1. Publish the NPM package from `npm-package`.
2. Publish the Docker Hub image from `release-images`.
9. Update the AUR package.
8. Update the AUR package.
- Instructions on updating the AUR package are at [cdr/code-server-aur](https://github.com/cdr/code-server-aur).
10. Wait for the npm package to be published.
11. Update the [homebrew package](https://github.com/Homebrew/homebrew-core/blob/master/Formula/code-server.rb).
1. Install [homebrew](https://brew.sh/)
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.
9. Wait for the npm package to be published.

## dev

Expand Down
2 changes: 1 addition & 1 deletion ci/build/release-prep.sh
Original file line number Diff line number Diff line change
Expand Up @@ -81,7 +81,7 @@ main() {
read -r -p "What version of code-server do you want to update to?"$'\n' CODE_SERVER_VERSION_TO_UPDATE

echo -e "Great! We'll prep a PR for updating to $CODE_SERVER_VERSION_TO_UPDATE\n"
$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"
$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"

# Ensure the tests are passing and code coverage is up-to-date
echo -e "Running unit tests and updating code coverage...\n"
Expand Down
15 changes: 15 additions & 0 deletions docs/MAINTAINING.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,8 @@
- [Versioning](#versioning)
- [Pull Requests](#pull-requests)
- [Merge Strategies](#merge-strategies)
- [Release](#release)
- [Release Manager Rotation](#release-manager-rotation)

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

Expand Down Expand Up @@ -75,3 +77,16 @@ If a PR does fix an issue, don't add it to the version milestone. Otherwise, the
### 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.
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