...
3d. Announce the creation of the Open edX release branch
Make a forum post announcing in the Announcement category saying that the branches have been cut and explaining what that means. For example:
Hey Open edX developers,
TL;DR: We are now in the pre-release phase for the next Open edX release: Palm. Code merged to master now will not be part of Palm. Keep this in mind as you make changes to master, especially needed fixes: They will need special attention, so reach out.
What is Palm? The next Open edX community release is named Palm. It will be based on the code as of today. We can include your future changes if you alert us to them.
What happened: Today we created the open-release/palm.master branches in our repos. As of now, changes you merge to master will contribute to the release after Palm, which will be called Quince.
What you should do: As you merge PRs to master, please be aware of fixes that might need to be applied to Palm. Let the Build-Test-Release Working Group know if there is a fix to be applied. They will need to be cherry-picked to ship as part of Palm, a.k.a. “backported”.
I know this gets confusing, but your code going onto master will now automatically be part of the Quince release (due next December). There is a new Quince wiki page for you to note things that will need to be considered when it comes time to release Quince. Please add features, caveats, and concerns to that page. If you are uncertain whether something should be mentioned there, add it. Or, talk to the Build-Test-Release WG and we'll figure it out.
What’s next? From now until the Palm release date, the Build-Test-Release group will be actively testing the release branch, finding bugs, triaging them, merging fixes to master, and backporting them to Palm. The Build-Test-Release Testing Coordinator will be kicking off this process soon, and they are happy to take volunteers to find and fix bugs. Keep an eye out if you’re interested. Even if you don’t actively participate, you can help this process by promptly reviewing any bugfix PRs that are made in your repositories.
Have questions? If you want to know more, we have an FAQ about the Open edX community releases. Please reach out if you have any questions.
--Ned, on behalf of the community Build/Test/Release working group.
Please x-post the announcement to the DEPR working group in the #wg-depr-slash-n-burn channel in the Open edX Slack, so that the DEPR working group can help write release notes of deprecated code in accordance with the DEPR Release Notes Process .
...
Prior to making a release (major, minor, or even a candidate), it is imperative that all known issues be fixed. You can check at the GitHub Project board with an appropriate filter such as “label:bug milestone:lilac.1”. Over time other labels or milestones may be incorporated, but just keep in mind that issues such as an uninstallable tag are unacceptable.
Search for open pull requests against the release branch. For example, for Nutmeg, we would search: https://github.com/pulls?q=is%3Aopen+is%3Apr+base%3Aopen-release%2Fnutmeg.master+archived%3Afalse.
...