Document the Major Release Process

[forhalle]

Document the steps needed to execute a major release of O3DE so that any O3DE contributor appointed by the #sig-release can successfully lead the execution of a major release.

Consider the differences between the work required for a point release (#44) and a major release.

Acceptance Criteria:

• A runbook (a set of copy-able tasks that must be performed to execute a point release)
  A Getting Started guide outlining the role of the Release Manager, definition of a major release, best practices, a link to the runbook, etc.

[forhalle]

The following items are needed for a major release, but not a point release (not a complete list):
(1) Per @sptramer :
A review of any and all "in-progress" banners that appear in docs should be carried out during every release stabilization period, before docs are frozen in the released set.
This would begin at the same time as stabilization is cut, at the beginning of hardening
(2) VS Upgrade tasks

[tonybalandiuk]

per #101 (reply in thread)
sig-graphics-audio can and should manage ASV releases.

Make sure this is included in release documentation

[tonybalandiuk]

@amzn-changml Can you weigh in on the need for VS upgrade tasks in the release process? is this still needed?

[amzn-changml]

It won't be needed unless the release:

1. Has a blocking issue with VS between releases (at which case a point release should be considered)
2. Has a major feature on the roadmap that requires the latest version of VS to be available

We do maintain a build node update cadence (defined here), but any bugs that arise from this during a release window will be part of the stabilization process

[tonybalandiuk]

@forhalle looking for your input here.
Based on the above response, any VS upgrade required seems to take care of itself for both 1 and 2, and the RM doesn't really need to do anything special, just be aware of this aspect of O3DE.

We have 2 options for documenting this:
A) a note in the release process mentioning 1) and 2)
OR
B) a task on the release project board which would require the RM to stop and think about this for each release.

[forhalle]

@tonybalandiuk - I do not understand how the upgrade "takes care if itself" for 2. I'm leaning towards a task on the release project board, but would like to understand this before giving my final opinion.

[tonybalandiuk]

@forhalle here's how I think it takes care of itself: If a major roadmap item requires a VS upgrade, then it would be up to the sig that owns that roadmap item or the contributor working on it to work with SIG-Platform and SIG-Build to get any support for VS in the build nodes. That roadmap item can't be submitted to the project unless that VS upgrade happens. So if the feature is in the release, then the VS support has been added. If it's not in the release, then it has not been added.
I don't see how sig-release would need to monitor this in any way or be involved in the management of the build system. So actually I'm leaning towards (A) as an FYI to the RM, and (B) seems unnecessary.

[forhalle]

@tonybalandiuk - Got it. In this case, I'm sticking with (A).