RC (Release Candidate) Generation process by Decoupling Release Notes

[prudhvigodithi]

Is your feature request related to a problem? Please describe

For today's release, having component release notes is an entry criteria, meaning the release notes must be merged into the release branch before generating the release candidate (RC). In past releases, this requirement was not strictly followed, as missing release notes could be a blocker for RC generation, preventing teams to test the RC. As a result, RC builds have been started even when some components were missing the release notes. This adds extra work for the release manager, who must follow up on missing release notes, and puts in situation where the locked RC commit ends up missing these notes.

Automations, such as the release notes check workflow, may fail because the input manifest includes a component commit that lacks release notes, leading to manual interventions like this PR which has the consolidated release notes.

Finalizing the RC before all entry criteria are met is not a good practice, but blocking the RC build until all plugin teams provide release notes is also inefficient, as it delays plugins that are ready for release.

Describe the solution you'd like

• Plugins should develop the habit of following to the entry criteria and adding the release notes.

• Maintain a new branch called release-notes where all plugins must add their release notes. This commit will not, and need not, be part of the RC, as it is neither a feature nor a bug fix. Moving forward, automations can use the release-notes branch to check version-specific release notes. The RC can be generated and finalized only after meeting the entry criteria of having the release notes, and having a separate release-notes branch ensures that the RC doesn't need to be rebuilt, since the branches are now independent.

• For example, if we start the build and later declare it as the RC, which is often done for patch releases, the RC need not be rebuilt just because the release notes were initially missing (adding release notes creates a new commit). With the release notes now added to the release-notes branch, the RC can be finalized, as the entry criteria of having release notes is met, without introducing a new commit to the release branch, avoiding unnecessary rebuilds.

Describe alternatives you've considered

No response

Additional context

No response

[prudhvigodithi]

Adding @dblock @getsaurabh02 @peterzhuamazon @gaiksaya @rishabh6788 to provide some inputs.

[peterzhuamazon]

Adding @dblock @getsaurabh02 @peterzhuamazon @gaiksaya @rishabh6788 to provide some inputs.

The issue I see is if user use the bundle manifest to get the commit, those commit will not contain the release notes.
I dont think we need to create a new branch to do that which will add more confusion.

Thanks.

[prudhvigodithi]

The issue I see is if user use the bundle manifest to get the commit, those commit will not contain the release notes.

Currently, it's not strictly necessary for a plugin's locked commit in the manifest to include release notes. I believe that while the commit should be stringent regarding code (whether it's a feature or bug fix) to ensure reproducible builds (as outlined at https://reproducible-builds.org/), release notes are not mandatory. By maintaining a common branch for all plugins and incorporating release notes there, we can address the following problems.

• Faster release candidate (RC) builds: A release manager no longer needs to wait (for an RC build) for all n components to add their release notes. While release notes are mandatory for minor releases, they are not required for patches, leading to multiple follow-ups to confirm whether it's okay to proceed with the RC and to check if the release notes have been added.

• Locking the RC Commit: If a release is notes is added after the RC build, we dont need to re-trigger the build again to in include the release branch commit as now all the release notes are pointing to the release-notes branch.

I see some advantages here, but we should start a META issue for this and get into the rabbit of adding the release notes to the release-notes branch. Also update the central release notes automation, release metrics to use the repo specific release-notes branch.