Branching & Release Strategy

Branches & Release Strategy

Branches in the main repository are used primarily for managing current and upcoming releases. Code development and enhancements should be done in a fork (see UPP Code Development).

A new branch is created when an application or operational implementation is ready to break from the develop branch in preparation to freeze the code for a release. During pre-release, modifications are submitted to the release branch as needed. Typically these modifications are minor (e.g., documentation updates), and changes to the code are kept minimal. Commits from the develop branch (e.g., major bug fixes) may be cherry-picked into the release branch as needed. The release branch is tested and bug fixes applied as needed. Once the release branch is deemed final, a release tag is created for use in that application. Relevant release branch changes should then be merged back to the develop branch. The release branch may persist through the life cycle of that application release, e.g., to allow for bug fixes to be applied directly to that application release, or it may be removed after the release tag is created, at the discretion of the application lead.

Naming Conventions

Each application may have its own naming convention for its respective release branches and/or release tags. Generally, release branches should be called "release/application-name-and-version". For example, the UFS release branches are called release/public-v#.

The authoritative UPP standalone releases have the following tag naming convention: upp_vX.Y.Z.

Versions

The UPP began its own versioning system within the repository in the Fall of 2020, beginning with v10.0.0. Versions are incremented in the develop branch at the discretion of the code managers, with effort to minimize the number of small patch or minor version updates due to the dependency of operational models' review and implementation requirements within NCEP.