[TB] Define release process, exit criteria and post-release actions

[aaronreed708]

Problem/Concern

We need to come up with what it means to "release" Theme Builder and the SDK. There needs to be an exit criteria and a series of post-release steps that must be completed. The purpose of this issue is to define both.

Proposed Solution

Here is a list with which to start defining the exit criteria. These are just some suggestions to serve as a starting point:

• Release candidate code is complete and available on dev branch
• Any updated documentation is available on dev branch
• Automated tests that have run to completion on the release candidate with 100% success.
• At least two maintainers attesting (in the release issue) to the fact that they ran manual tests against the release candidate.
  • In the SDK perhaps this is an attestation that the maintainers ran Theme Builder tests that are meant to exercise the SDK in particular
  • Theme Builder tests should be run on both locally built Docker image and Netlify deploy
• Version must be bumped before commit to main
• Release notes must be updated, include the new version number and release date
• Dev pushed to main
• Tests re-run on main deploy on Netlify and on published Docker image
• Verify updated documentation has been deployed

Here is a list with which to start defining the exit criteria. These are just some suggestions to serve as a starting point:

• Version number discoverable from inside application? Verify version correct in code, in container registries, in NPM (if SDK updated) and deployed application before announcement
• Link to release notes in the application?
• FINOS marketing team is informed. (Juan & Mao can put us in contact with them).

[aaronreed708]

From @maoo: "I'd suggest to look at Github features that automatically generate Release notes, see https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes. Note that Github Actions can be triggered by new releases, which would allow you to use the Github UI to trigger the release process, and Github actions to build and publish artifacts"

[aaronreed708]

The release process needs to include manual Docker scanning for now, as well as linking the manual scan results with the release somehow (more background information here: #742)

[PaulaPaul]

I'll be looking into #721 as part of this and will explore @maoo 's suggestion for automatic release notes from GitHub), and @codyzu 's suggestion for beachball. Both are integrated with GitHub - will put notes here as I create examples from both and we can decide which way we'd like to go.