Release template improvement suggestions

[dbwiddis]

The penultimate step in the curent release template directs to

• Suggest improvements to this template.

So I'm doing that. Here's a list of things I've noted during 2.14 release so far.

• Release issue refers to dates in linked issue but checklists do not align, and the only relevant date available is 4/30. The checklist has multiple phases including “Preparation” and “Pre-Release”. What needs to be done at code freeze date? First RC Generation? How will final release date be communicated? Specifically:

  • Last step in Preparation is cutting release branch. No deadline listed (Should be RC Generation minus 1 day?)
  • Release notes needed in Pre-Release but also need date finalized in Release section. No deadlines for either step?

• Lots of duplication of steps related to "Code Complete":

  • “Finalize the code” in preparation step
  • “All code changes are complete” in CI/CD
  • “Confirm that all changes have been merged” in Pre-release.
  • “Code Compete” in Release Testing

• No dates are given for documentation checkoff. Is there a “documentation freeze” date to allow doc team review time?

• “Manifest for the next development iteration” is unclear (is that 2.15?) and these manifests are generally not under repo control. Shouldn’t this just be a copy of current release manifest handled by release automation tools? Should the checklist say something about “changes to the manifest from this release for the next iteration”? In general, can we clarify which steps in the template will be done by automation and which repo owners are responsible for?

• Repos have release issues for 3.0.0. This is far in the future and there’s no mechanism to update/edit those checklists based on retrospectives. These clutter up issue lists.

• Post Release includes preparation for a development iteration by incrementing the version. This is generally automated, the checklist should mention that a PR will be created for this.

  • There’s also a mention of adding it to the manifest. Does this duplicate the manifest mentioned in the Pre-Release section? Is this a repo responsibility or release automation?

• Several repos have the GitHub "Releases" section where they convert the released tag to a release. This is not mentioned anywhere in the checklist. It should be (with an "if applicable" caveat)

[prudhvigodithi]

[Triage]
Thanks @dbwiddis, as you suggested we can improve and update the template, the another approach I was thinking is keep the global release issue (part of the build repo, ex 2.14.0) as the single source source of truth to surface all the release related information.

In the progress of the release cycle there are lot of changes (sometimes including dates) are added/updated to the release issue, its very tedious process now go back and update all the component release issues with specific information for a release manager. Today even though the creation of component release issues is automated the update is not. Also sometimes not all component release issues are acknowledged and I did notice in past they remain untriaged with no assignee even after the release.

So I would like to reduce this overhead and keep the global release issue as the single source of truth with all the information as needed for a component release manager.

One drawback I see for this is there is no information about the component level release manager, today a release manager will be tagging the assignee of the component release issue when there is an action required from a component (plugin). To fix this I would propose to have an additional entry criteria to have a component level release manager assigned and this can be taken care by the repo maintainers.

Adding @bbarani @gaiksaya @peterzhuamazon @rishabh6788 @dblock