On Thu, Feb 27, 2020 at 8:15 AM Abdelatif Guettouche <abdelatif.guettou...@gmail.com> wrote: > We also need to define our release process. > Something like: > Create a branch from master that will serve as a release candidate. > Make the necessary modifications in preparation of a release (update > release notes, documentation, etc.) > Accept only critical bug fixes to the RC, other PRs should still go to master. > > This is not a release process proposition, just a draft that I'm > writing in a hurry.
I'm thinking something along these lines: 1. Pick a branch date ahead of time and announce it so that people can try to get last-minute work in on time for the release. 2. Create the branch on that date. 3. All commits continue to go to Master. Bugfixes that should be in the release are then backported from Master to the release branch. 4. Run build tests. 5. Create release candidate tarballs. 6. Start soak period (we need to determine how long the soak period should be) to give downstream time to find/report/fix bugs. 7. If necessary, backport bug fixes and issue another release candidate. 8. When no more showstopper issues remain, create release tarballs. 9. Sign the release tarballs. When someone signs a release tarball, they are essentially voting to release, implying that they've done some testing/oversight, and also saying that the release tarballs are authentic. Anyone can sign to increase the web of trust of a release, but we need to determine how many minimum PPMC / IPMC signatures are required to release. Did I forget any steps? Thoughts? Feedback? Thanks, Nathan
