RelEng: PostMortem2.7

Problems with the 2.7 release process to address

• What things did we learn from the 2.7 release process?
• For the RMs to discuss to make a better unified release process going forward.

Development

• Add more Changelog categories
  • trivial for things that should only be rendered between pre-releases
  • what is a major_change vs minor_change vs trivial_change? Playbook-breaking is definitely major_change. Additions to the playbook keywords? Changes to how a playbook keyword acts?
  • Optimizations: bugfix or *_change?

Pre-branch

• I think we want to go back to having a tracker project pre-branch but remove it once we get to post-branch. The reason is that post-branch we can use the github query to tell what backport PRs exist against the stable-X.Y branch. But pre-branch, we just have to remember what things people have asked to be included.

Branches

• Should we use long pre-release version tags or short ones? "alpha vs a", "beta vs b". 2.4 and previous used alpha/beta. 2.5 and 2.6 use a and b. alpha and beta are easier for users to read. We may have to check that we're using packaging.versioning everywhere we need to compare versions in our releng scripts?
• After branching, bot automerge may be enabled and green, but a PR will have a stale version_added. There may need to be a way to find all new_plugin/new_module PRs and rerun CI after the version is changed in release.py.

Schedule

• Two weeks between beta and rc is good because we release the last beta on Thursday or Friday and also stop merging for rcs on Monday so that tower has a chance to test before Thursday. With only one week in between, fixes that need to make it into rc1 would have to be written over the weekend and merged on Monday.... not really enough time.
• We need to be ready for downstream releases by the time we reach the first upstream RC to maximize the time available for downstream testing.

Communication

• After at least one RC is available, the incoming RM (2.8 RM in this case) needs to prep a list of support-impacting features and changes for the Support Readiness Meeting with CEE
• Appears that marketing would like to know about RCs and that wasn't on the process doc.
  • That's been fixed
  • Reach out to all teams (marketing, tower, support, other?) to have them review the notification section?