diff options
Diffstat (limited to 'docs/dev/README.md')
-rw-r--r-- | docs/dev/README.md | 33 |
1 files changed, 24 insertions, 9 deletions
diff --git a/docs/dev/README.md b/docs/dev/README.md index 9c0eb1358..16b23adc6 100644 --- a/docs/dev/README.md +++ b/docs/dev/README.md | |||
@@ -208,20 +208,26 @@ Release process is handled by `release`, `dist` and `promote` xtasks, `release` | |||
208 | 208 | ||
209 | Additionally, it assumes that remote for `rust-analyzer` is called `upstream` (I use `origin` to point to my fork). | 209 | Additionally, it assumes that remote for `rust-analyzer` is called `upstream` (I use `origin` to point to my fork). |
210 | 210 | ||
211 | `release` calls the GitHub API calls to scrape pull request comments and categorize them in the changelog. | ||
212 | This step uses the `curl` and `jq` applications, which need to be available in `PATH`. | ||
213 | Finally, you need to obtain a GitHub personal access token and set the `GITHUB_TOKEN` environment variable. | ||
214 | |||
211 | Release steps: | 215 | Release steps: |
212 | 216 | ||
213 | 1. Inside rust-analyzer, run `cargo xtask release`. This will: | 217 | 1. Set the `GITHUB_TOKEN` environment variable. |
218 | 2. Inside rust-analyzer, run `cargo xtask release`. This will: | ||
214 | * checkout the `release` branch | 219 | * checkout the `release` branch |
215 | * reset it to `upstream/nightly` | 220 | * reset it to `upstream/nightly` |
216 | * push it to `upstream`. This triggers GitHub Actions which: | 221 | * push it to `upstream`. This triggers GitHub Actions which: |
217 | * runs `cargo xtask dist` to package binaries and VS Code extension | 222 | * runs `cargo xtask dist` to package binaries and VS Code extension |
218 | * makes a GitHub release | 223 | * makes a GitHub release |
219 | * pushes VS Code extension to the marketplace | 224 | * pushes VS Code extension to the marketplace |
220 | * create new changelog in `rust-analyzer.github.io` | 225 | * call the GitHub API for PR details |
221 | 2. While the release is in progress, fill in the changelog | 226 | * create a new changelog in `rust-analyzer.github.io` |
222 | 3. Commit & push the changelog | 227 | 3. While the release is in progress, fill in the changelog |
223 | 4. Tweet | 228 | 4. Commit & push the changelog |
224 | 5. Inside `rust-analyzer`, run `cargo xtask promote` -- this will create a PR to rust-lang/rust updating rust-analyzer's submodule. | 229 | 5. Tweet |
230 | 6. Inside `rust-analyzer`, run `cargo xtask promote` -- this will create a PR to rust-lang/rust updating rust-analyzer's submodule. | ||
225 | Self-approve the PR. | 231 | Self-approve the PR. |
226 | 232 | ||
227 | If the GitHub Actions release fails because of a transient problem like a timeout, you can re-run the job from the Actions console. | 233 | If the GitHub Actions release fails because of a transient problem like a timeout, you can re-run the job from the Actions console. |
@@ -229,18 +235,27 @@ If it fails because of something that needs to be fixed, remove the release tag | |||
229 | Make sure to remove the new changelog post created when running `cargo xtask release` a second time. | 235 | Make sure to remove the new changelog post created when running `cargo xtask release` a second time. |
230 | 236 | ||
231 | We release "nightly" every night automatically and promote the latest nightly to "stable" manually, every week. | 237 | We release "nightly" every night automatically and promote the latest nightly to "stable" manually, every week. |
238 | |||
232 | We don't do "patch" releases, unless something truly egregious comes up. | 239 | We don't do "patch" releases, unless something truly egregious comes up. |
240 | To do a patch release, cherry-pick the fix on top of the current `release` branch and push the branch. | ||
241 | There's no need to write a changelog for a patch release, it's OK to include the notes about the fix into the next weekly one. | ||
242 | Note: we tag releases by dates, releasing a patch release on the same day should work (by overwriting a tag), but I am not 100% sure. | ||
233 | 243 | ||
234 | ## Permissions | 244 | ## Permissions |
235 | 245 | ||
236 | There are three sets of people with extra permissions: | 246 | There are three sets of people with extra permissions: |
237 | 247 | ||
238 | * rust-analyzer GitHub organization **admins** (which include current t-compiler leads). | 248 | * rust-analyzer GitHub organization [**admins**](https://github.com/orgs/rust-analyzer/people?query=role:owner) (which include current t-compiler leads). |
239 | Admins have full access to the org. | 249 | Admins have full access to the org. |
240 | * **review** team in the organization. | 250 | * [**review**](https://github.com/orgs/rust-analyzer/teams/review) team in the organization. |
241 | Reviewers have `r+` access to all of organization's repositories and publish rights on crates.io. | 251 | Reviewers have `r+` access to all of organization's repositories and publish rights on crates.io. |
242 | They also have direct commit access, but all changes should via bors queue. | 252 | They also have direct commit access, but all changes should via bors queue. |
243 | It's ok to self-approve if you think you know what you are doing! | 253 | It's ok to self-approve if you think you know what you are doing! |
244 | bors should automatically sync the permissions. | 254 | bors should automatically sync the permissions. |
245 | * **triage** team in the organization. | 255 | Feel free to request a review or assign any PR to a reviewer with the relevant expertise to bring the work to their attention. |
256 | Don't feel pressured to review assigned PRs though. | ||
257 | If you don't feel like reviewing for whatever reason, someone else will pick the review up! | ||
258 | * [**triage**](https://github.com/orgs/rust-analyzer/teams/triage) team in the organization. | ||
246 | This team can label and close issues. | 259 | This team can label and close issues. |
260 | |||
261 | Note that at the time being you need to be a member of the org yourself to view the links. | ||