|
1 | | -# Get the build green (Early in endgame week) |
| 1 | +* [Endgame Template](https://github.com/microsoft/vscode-jupyter/blob/main/.github/release_plan.md) |
| 2 | + |
| 3 | +## Thursday |
2 | 4 |
|
3 | 5 | - [ ] Ensure that any CI test failures have issues assigned to that area's owner. |
4 | 6 | - [ ] Work with the build champ to drive the build to green by fixing/disabling tests or pinging area owners to do so. |
5 | 7 |
|
6 | | -# Release candidate (Friday of endgame week) |
7 | | -- [ ] Review [Component Governance](https://dev.azure.com/monacotools/Monaco/_componentGovernance/191876) (Click on "microsoft/vscode-jupyter" on that page) and resolve all High/Severe issues. |
8 | | - - [ ] Focus on resolving `Critical` and `High` priority issues as others will be addressed in the `debt` week. |
9 | | - - [ ] Manually add any repository dependencies (if you can't add manually, refer [here](https://docs.opensource.microsoft.com/tools/cg/features/cgmanifest/)). Only add a cgmanifest.json if the components are not NPM or are not dev only. |
| 8 | +## Friday |
| 9 | +- [ ] Review [Component Governance](https://dev.azure.com/monacotools/Monaco/_componentGovernance/191876) (Click on "microsoft/vscode-jupyter" on that page) and resolve all High/Severe issues. |
| 10 | + - [ ] Focus on resolving `Critical` and `High` priority issues as others will be addressed in the `debt` week. |
| 11 | + - [ ] Manually add any repository dependencies (if you can't add manually, refer [here](https://docs.opensource.microsoft.com/tools/cg/features/cgmanifest/)). Only add a cgmanifest.json if the components are not NPM or are not dev only. |
10 | 12 | Instructions on updating `npm` dependencies in `package.json` & `package-lock.json` can be found [here](https://github.com/microsoft/vscode-jupyter/wiki/Resolving-Component-Governance-and-Dependabot-issues-(updating-package-lock.json)). |
11 | | -- [ ] Create new release branch with format `release/release-YYYY.MM`. |
12 | | - - [ ] Update [`ThirdPartyNotices-Repository.txt`](https://github.com/Microsoft/vscode-jupyter/blob/main/ThirdPartyNotices-Repository.txt) as appropriate. This file is manually edited so you can check with the teams if anything needs to be added here. |
13 | | -- [ ] Disable [the pre-release devops pipeline](https://dev.azure.com/monacotools/Monaco/_build?definitionId=283). (`...` menu > Settings > Processing of new requests: Disabled) |
14 | | -- [ ] Create a PR to `main` with the following changes... (Warning: this should happen right after creating the release branch. If this is deferred till later, the `main` and `release` branches can diverge significantly, which may cause merge conflicts.) |
15 | | - - [ ] Merge the changes from release (ThirdPartyNotices) into `main` branch |
16 | | - - [ ] At this point, the vscode engine version should also be the same as in the release branch- will be bumped when the next release happens |
17 | | - - [ ] Bump the version number to the next monthly ("YYYY.M.100") version number (e.g. if the latest is `2022.2.100`, bump it to `2022.3.100`). |
18 | | - - [ ] Run `npm install` to update `package-lock.json` |
19 | | - |
20 | | -# Testing (Monday of VS Code release week) |
21 | | - |
22 | | -- [ ] Obtain VS Code [stable RC](https://builds.code.visualstudio.com/builds/stable) for sanity testing |
23 | | -- [ ] Sanity test release candidate VSIX against VS Code RC |
24 | | - - Create a VSIX to sanity test by running the [Stable pipeline](https://dev.azure.com/monacotools/Monaco/_build?definitionId=284) against the `release/release-YYYY.MM` branch |
25 | | - - You do not need an approval to build the VSIX, but you can keep the pipeline running and ask for an approval once the sanity test is successful to publish it. |
26 | | - - Make sure that the sanity test hits both macOS and Windows builds |
27 | | -- [ ] Candidate bug fixes found from sanity test should be checked into `main` and cherry-picked to `release` branch |
28 | | - - After a candidate fix is merged, a pre-release build can be released by manually running [the pre-release devops pipeline](https://dev.azure.com/monacotools/Monaco/_build?definitionId=283) against the release branch. |
29 | | - |
30 | | -# Release (Tuesday or day before VS Code publishes, whichever is later) |
31 | | - |
32 | | -## Preparation |
33 | | - |
34 | | -- [ ] Make sure [Component Governance](https://dev.azure.com/monacotools/Monaco/_componentGovernance/191876) is happy |
35 | | - |
36 | | -## Release |
37 | | - |
38 | | -- [ ] Verify the PR Pipeline on Github actions is green against the release branch. |
39 | | -- [ ] Manually run the [Stable pipeline](https://dev.azure.com/monacotools/Monaco/_build?definitionId=284) against the `release/release-YYYY.MM` branch |
40 | | -- [ ] Approve the `Publish` stage |
41 | | -- [ ] Push a tag with the released version number on the commit that was released |
42 | | -- [ ] If any steps were unclear or changed in this release plan please update the `release_plan.md` file to make it clear for the next release |
43 | | - |
44 | | -# Day of VS Code releasing the next insider version (Wednesday) |
45 | | -- [ ] Bump the engines.vscode version on the `main` branch to point to the next version. For example, from `1.58.0` to `1.59.0` |
46 | | -- [ ] Reenable [the pre-release devops pipeline](https://dev.azure.com/monacotools/Monaco/_build?definitionId=283) (`...` menu > Settings > Processing of new requests: Enabled) |
47 | | - |
48 | | -# As needed |
49 | | - |
50 | | -- [ ] Determine if a hotfix is needed |
51 | | - - Use the same `release/release-YYYY.MM` branch |
52 | | - - [ ] Ensure the version in package.json is updated as follows: |
53 | | - * If released version is `YYYY.MM.100`, then hot fix will be `YYYY.MM.110` |
54 | | - * If released version is `YYYY.MM.110`, then hot fix will be `YYYY.MM.120` |
55 | | - - [ ] Push another tag for the new version's commit |
| 13 | +- [ ] Create new release branch with format `release/release-YYYY.MM`. |
| 14 | + - [ ] Update [`ThirdPartyNotices-Repository.txt`](https://github.com/Microsoft/vscode-jupyter/blob/main/ThirdPartyNotices-Repository.txt) as appropriate. This file is manually edited so you can check with the teams if anything needs to be added here. |
| 15 | +- [ ] Disable [the pre-release devops pipeline](https://dev.azure.com/monacotools/Monaco/_build?definitionId=283). (`...` menu > Settings > Processing of new requests: Disabled) |
| 16 | +- [ ] Create a PR to `main` with the following changes... (Warning: this should happen right after creating the release branch. If this is deferred till later, the `main` and `release` branches can diverge significantly, which may cause merge conflicts.) |
| 17 | + - [ ] Merge the changes from release (ThirdPartyNotices) into `main` branch |
| 18 | + - [ ] At this point, the vscode engine version should also be the same as in the release branch- will be bumped when the next release happens |
| 19 | + - [ ] Bump the version number to the next monthly ("YYYY.M.100") version number (e.g. if the latest is `2022.2.100`, bump it to `2022.3.100`). |
| 20 | + - [ ] Run `npm install` to update `package-lock.json` |
| 21 | + |
| 22 | +## Monday (Debt/Release week) |
| 23 | + |
| 24 | +- [ ] Obtain VS Code [stable RC](https://builds.code.visualstudio.com/builds/stable) for sanity testing |
| 25 | +- [ ] Manually run the [Stable pipeline](https://dev.azure.com/monacotools/Monaco/_build?definitionId=284) against the `release/release-YYYY.MM` branch |
| 26 | + - Enable `Publish Extension`, you do not need an approval to build the VSIX. |
| 27 | + - DO NOT ask for approval for the extension publish step, this step should only be done after sanity testing is done and ready to release. |
| 28 | +- [ ] Sanity test release candidate VSIX against VS Code RC |
| 29 | + - [ ] Windows |
| 30 | + - [ ] win32-x64 |
| 31 | + - [ ] win32-ia32 |
| 32 | + - [ ] win32-arm64 |
| 33 | + - [ ] macOS |
| 34 | + - [ ] darwin-x64 |
| 35 | + - [ ] darwin-arm64 |
| 36 | + - [ ] Linux |
| 37 | + - [ ] linux-arm64 |
| 38 | + - [ ] linux-armhf |
| 39 | + - [ ] linux-x64 |
| 40 | + - [ ] alpine-arm64 |
| 41 | + - [ ] alpine-x64 |
| 42 | + - [ ] Web |
| 43 | +- [ ] Candidate bug fixes found from sanity test should be checked into `main` and cherry-picked to `release` branch |
| 44 | + - After a candidate fix is merged, a pre-release build can be released by manually running [the pre-release devops pipeline](https://dev.azure.com/monacotools/Monaco/_build?definitionId=283) against the release branch. |
| 45 | + |
| 46 | +## Tuesday |
| 47 | + |
| 48 | +- [ ] Make sure [Component Governance](https://dev.azure.com/monacotools/Monaco/_componentGovernance/191876) is happy |
| 49 | +- [ ] Release |
| 50 | + - [ ] Verify the PR Pipeline on Github actions is green against the release branch. |
| 51 | + - [ ] Approve the `Publish` stage of the last [Stable pipeline](https://dev.azure.com/monacotools/Monaco/_build?definitionId=284) that's successfully sanity tested. |
| 52 | + - [ ] Push a tag with the released version number on the commit that was released |
| 53 | + - [ ] If any steps were unclear or changed in this release plan please update the `release_plan.md` file to make it clear for the next release |
| 54 | + |
| 55 | +## Wednesday/Thursday (Day of VS Code releasing the next insider version) |
| 56 | +- [ ] Bump the engines.vscode version on the `main` branch to point to the next version. For example, from `1.58.0` to `1.59.0` |
| 57 | +- [ ] Reenable [the pre-release devops pipeline](https://dev.azure.com/monacotools/Monaco/_build?definitionId=283) (`...` menu > Settings > Processing of new requests: Enabled) |
| 58 | + |
| 59 | +## As needed |
| 60 | + |
| 61 | +- [ ] Determine if a hotfix is needed |
| 62 | + - Use the same `release/release-YYYY.MM` branch |
| 63 | + - [ ] Ensure the version in package.json is updated as follows: |
| 64 | + * If released version is `YYYY.MM.100`, then hot fix will be `YYYY.MM.110` |
| 65 | + * If released version is `YYYY.MM.110`, then hot fix will be `YYYY.MM.120` |
| 66 | + - [ ] Push another tag for the new version's commit |
0 commit comments