We have release procedures for the following scenarios:
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:
Create a new frontend tag. The releases can be found here:
already have a MAJOR.MINOR number for this release. Increment the PATCH
number, i.e. MAJOR.MINOR.PATCH. Look at what new commits are in this release
compared to the old release by using e.g.:
Adjust the tag and branch name in between the
... of the link accordingly
to see the new commits. Add significant PRs and issues to the release log:
same style as the other releases shown in:
https://github.com/cBioPortal/cbioportal-frontend/releases. You can save
your work as a draft if necessary.
Once the frontend code is tagged, create a pull request to the backend repo
where the frontend version is incremented in
Once that PR is merged, one can create a tag for the backend repo with the
same tag as the frontend repo. Copy over the release log from the frontend
repo. You can look at backend specific commits in the same manner:
the release log of frontend and backend should be identical. Both list the
significant frontend and backend changes. You can update existing release
logs using the github interface.
For new feature releases, 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:
Make sure no auto deployment is running for frontend from netlify
Merge frontend release-x.y.z branch to frontend master
Follow same procedure as for [a PATCH
but instead of having a separate PR to update the frontend (step 2) one can
add it to the already existing backend branch release-x.y.z and open the PR
from there to backend's master. This is merely for convenience to avoid
having to create another branch just to update the frontend version.
We follow the following logic when deciding how/when to increment the version of cBioPortal. It's a complete modification of semantic versioning (MAJOR.MINOR.PATCH) more suitable for our purposes:
MAJOR : A big change in how cBioPortal works. We changed the major version from 1 to 2 when we completely moved from using JSPs to a Single Page App written in React calling a REST service.
MINOR : Backwards incompatible features that requires both backend and frontend changes. If the frontend change is very significant we can increase the MINOR version as well.
PATCH : Backwards compatible fixes. Can be e.g. frontend only changes or fixes to backend.