Release Management/Release Process Checklist Documentation: Difference between revisions

# If there are security bugs uplifted then sync with the security team member on [https://docs.google.com/spreadsheets/d/1RbryXhVp2fWeukXixgqSdVQckd7A3YwEubQWgMacEO0/edit?gid=0#gid=0 rotation]

#* The team member on rotation will assign the CVEs and prepare the advisories. This also covers any Android advisories.

#* Add a release note with a link to the major release for reference.

#* For bugs that have been identified as needing a release note:

#** If a release note is required and the release note text is clear from the bug content then create it directly in Nucleus.  

#** Otherwise, request wording before adding the release note.

#* If any uplifts impact Android then duplicate the Android Dot Release Checklist tab and name it appropriately.

# Follow the same process as monitoring when an RC build has QA sign-off

#* Example: Android 101.0.1

# Follow the same process as creating an RC build with the following exceptions:

##* This allows you to submit an app for review but control when it is published.

##* If an app is still pending review on a closed track then you cannot promote it to a production track.

##* See [https://support.google.com/googleplay/android-developer/answer/9859348?hl=en Prepare and roll out a release] for more information.

##* Keep the same release notes as the major release. Add any new notes at the top prefixed by the dot release version.

##* With managed publishing turned on, the app will not automatically release after the store review.

# Follow the same process as monitoring when an RC build has QA sign-off with the following exceptions:

##* With managed publishing turned off, the app will be automatically released after store review.