Update release procedure protocol (#10644)

docs/development/Release-Procedure.md

@@ -7,7 +7,7 @@ We have release procedures for the following scenarios:
 
 ## cBioPortal community release of code already in production
 
-We often run code in production that is not ready yet for use by the wider cBioPortal community. We deploy to production what's in the master branch of the backend repo and the frontend repo. Often times this is not a tagged release. At some point this code should be released for the wider community. These are the steps we follow:
+We often run code in production that is not ready yet for use by the wider cBioPortal community. The frontend gets deployed to production after every merge to master. The backend gets updated every Tuesday before our community call (occasionally more frequently too if issues are identified). We tag whatever is in the master and frontend repo and put a "Pre-Release" indication on it. After a month of stable usage in production, one of the tags will get the "latest" indication on the GitHub. These are the steps we follow to create a release:
 
 1. Create a new frontend tag. The releases can be found here: https://github.com/cBioPortal/cbioportal-frontend/releases. A draft of the release notes are automatically generated by https://github.com/marketplace/actions/release-drafter. If there are pull requests in the `Changes` section i.e. they have not been labeled with one of the labels defined [here](https://github.com/cBioPortal/cbioportal-frontend/blob/master/.github/release-drafter.yml). Try to label them and trigger a rerun by committing something to the master branch. Alternatively you can manually put them in a particular section. Note that our goal is to have automated release notes, so it would be great if you could send a PR to update the [release-drafter.yml](https://github.com/cBioPortal/cbioportal-frontend/blob/master/.github/release-drafter.yml) in case you find certain PRs don't fit in a particular section or a section should be altered. Look at other release notes for inspiration: https://github.com/cBioPortal/cbioportal-frontend/releases. You can save your work as a draft if necessary.
 2.  Once the frontend code is tagged, create a pull request to the backend repo where the frontend version is incremented in `portal/pom.xml`:
@@ -26,6 +26,9 @@ We often run code in production that is not ready yet for use by the wider cBioP
     then put them in the right sections following same style as other releases: https://github.com/cBioPortal/cbioportal-frontend/releases.
 4. Create a news item with a link to your carefully crafted release notes. Highlight a few major changes that could be interesting to users of cBioPortal ideally with a screenshot similar to: https://github.com/cBioPortal/cbioportal/pull/6914/files?short\_path=6f95322#diff-6f953229832059bab3fe229d4af08b52 (in the files changed section, you can click on view rich diff to see the converted markdown).
 
+## Backend Hotfixes
+Occasionally there are bugs identified in the backend running in production. Creating an entire new release can be cumbersome so in this case, we create a new release branch instead. E.g. if the current release is `6.0.2`, the new branch would be `release-6.0.3`. Any fixes are then merged to this branch and if it looks good, they are deployed to production. On the following Tuesday whatever's in this `release-x` branch get merged to master and included in that Tuesday's release. 
+
 ## Release with database migration
 
 For releases with database migrations, we increase the MINOR number in MAJOR.MINOR.PATCH. For those releases we have a separate branch (see https://github.com/cBioPortal/cbioportal/blob/master/CONTRIBUTING.md#branches-within-cbioportal), which needs to be merged to master on both backend and frontend: