Update Publishing Instructions #2601
Conversation
| - [ ] Sprint column is free from QA reported blocking issues | ||
| - [ ] QA approved the release | ||
| - [ ] All hotfixes to previous releases have been merged into the release (and develop) branch | ||
| - [ ] CHANGELOG.md is up to date | ||
| - [ ] All hotfixes for issues discovered in alpha releases have been merged into the release (and develop) branch |
There was a problem hiding this comment.
I don't think this line is equivalent to the one that it replaces. In some cases we'll make full releases (not alpha releases) that include a hotfix to a previous release. We then need to make sure these hotfixes are brought over to the new release because it's possible someone forgot to add them to both the hotfix branch and develop at the time they were created. Does this make sense?
There was a problem hiding this comment.
I don't think that entirely makes sense as a rule because there may be cases where hotfixes applied to a previous release are solved in more robust way through a refactor in the develop branch, and in that case, it wouldn't make sense to cherry pick the hotfix applied to an old release. To me, it seems better to just focus on ensuring that at the time of a release (alpha or production) merges the appropriate commits from the release branch to develop. Otherwise, there becomes this question of how many previous releases back will we comb through every commit in that release branch to check if it was cherry picked to develop or not, and if that change should be applied to the current release or if it was fixed in another way.
PUBLISHING.md
Outdated
|
|
||
| ## Post-release checklist (production) | ||
| - [ ] Download links are updated on a website and in README.md | ||
|
|
||
| - [ ] Download links are updated on website and in README.md |
There was a problem hiding this comment.
I think we can cut "and in README.md" because that download link now links to the downloads section on the website.
PUBLISHING.md
Outdated
|
|
||
| - [ ] Release branch is created from `develop` branch with the production version number, e.g. `2.1.0`. | ||
| - [ ] Reviewed the base `CHANGELOG.md` file and ensured that it is up to date with all changes included in the release since the last production release. Package level `CHANGELOG.md` files are automatically updated during the release process. | ||
| - [ ] Approved the updated `CHANGELOG.md` file with the @holmesworcester. |
There was a problem hiding this comment.
We can cut this since it repeats later.
The main idea here is that CHANGELOG is a public facing document that we want to be clear, readable, and meaningful, and that conforms more or less to the style described in publishing guidelines.
There was a problem hiding this comment.
I'm just going to remove the approval part from the alpha release section because I think its valuable for QA to have an updated changelog for the alpha too
Adds more detail to publishing instructions to clear up some confusion about process.