ADR Suggestion: Defining the release process and release manager role

[krzywon]

I started to write a draft of this ADR and realized it will likely require a series of sub-ADRs for this to be fully defined. A handful of these ADRs are already written, but others are still required. This ADR suggestion will act as a tracker ADR that will define the sub-ADRs necessary to define our entire process.

Defining the Release Process and the Release Manager Role

Preamble

To ensure a consistent release process between different releases and different repositories, all processes and roles must be clearly defined. This proposal will include the versioning schema, managing release notes, the process for creating a release, and whom should manage each step of the process.

Proposal

Each release for each repository should follow the same process to ensure consistency between versions as well as repositories.

Required sub-ADRs

As topic-specific ADRs are written, they will be added as a comment here.

• The role of the release manager needs to be defined
  • Selecting the release manager
  • Release manager responsibilities
  • Release manager benefits
• Define the steps required prior to, during, and after each release cycle
  • Timeline for a code freeze
  • Selecting what goes into each release
  • Defining what can be added at each point in the process (alpha, beta, rc, etc)
  • post-releases vs patch releases
• Contributors and Zenodo authorship
  • Convert https://github.com/SasView/sasview/wiki/contribution_acknowledgments to an ADR
• Versioning, including consistent tagging, and release names
  • Semantic versioning: https://semver.org/
• What steps of the release process can and should be automated and when and how should these automated steps be performed
  • Proposed ADR: https://github.com/orgs/SasView/discussions/3475
• What format should release notes be in, and what should prerelease notes include
• Release citations
  • Approved ADR: https://github.com/orgs/SasView/discussions/3876
• Version pinning at code freeze
  • Approved ADR: https://github.com/orgs/SasView/discussions/3831
• Distributable files
  • PyPi, Conda, binaries, and compressed source code files

[rozyczko]

How do we propose to define "Ready to Release"?

The proposal mentions a feature freeze, but who makes the final call on blocking bugs versus known issues?
We say that blockers are being discussed on calls. Maybe we can have release criteria explicitly set the process, e.g.:

• A release-blocker label on issues

• A "community check" period after the final release candidate (RC) where no new changes are merged

Maybe one of the roles/responsibilities of the RM be the ability to pause or halt the release process if critical criteria aren't met?

[krzywon]

Good points and I think those will be needed when writing the release process steps and release manager definition. When I started writing this proposal, I quickly realized how massive the entire ADR would be if it was all here, so I really only hit the major bullets.