Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Release Docs #183

Merged
merged 1 commit into from
Jan 4, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,18 @@ Documentation](https://nasa.github.io/cumulus/docs/deployment/deployment-readme)
for detailed information about configuring, deploying, and running
Cumulus.

## Generating Releases

### Naming Schema:
The CIRRUS name schema is `vX.X.X.Y`. The X represents the [Cumulus version](https://github.com/nasa/cumulus/releases),
while the Y represents the CIRRUS version.

### Backporting Features
A release branch should be created when backporting a feature, such as `release/v17.1.4.2`.
In this case, the release branch `release/v17.1.4.2` should be created from the tag `v17.1.4.1`.
Comment on lines +34 to +35
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you'd want to include the CIRRUS version in the release branch name. You probably don't need the entire cumulus version either. It makes more sense to me to have a release/v17 branch that you make tags off of just like you would with master for the latest releases. That way you can maintain that branch as long as that cumulus version needs to be supported, and if there are updates to cumulus you can pull those in without creating inconsistencies with the branch name.

No reason why for backports you need to create a separate branch for every release, that's what tags are for.

You should then create a PR from your feature branch to the release branch.
Once the PR has been approved and merged, you can create a release based on the release branch.

## Prerequisites

* [Docker](https://www.docker.com/get-started)
Expand Down
Loading