Release Management

Release Management

Versioning

All Stepup applications and libraries follow Semantic Versioning 2.0.0. The complete specification can be read there.

In short, given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards-compatible manner, and
• PATCH version when you make backwards-compatible bug fixes.

Branching model

All Stepup applications and follow a branching model.

In short:

• all work is performed in branches, like feature/add-button, bugfix/syntax-fix, maintenance/update-dependencies;
• which is merged to the development branch, develop;
• releases are prepared on release branches by merging develop into a release branch, like release-1.5;
• and releases are tagged on master or on a release branch (when multiple versions are maintained), by merging in the latest release branch and tagging.

Note that all merging is performed without fast-forwards by specifying --no-ff.

Release management

Before a version may be released:

• the test suite must pass;

• and the changelog must be updated.

• the changelog is written using Markdown and should be formatted like so:

  # Upcoming release
  Release description, consider categorizing the changes when many changes are applied.     
  
  # 1.2.1
  Release description
  
  # 1.2.0
  Release description

  The changelog for the main applications is tracked in the Stepup-Deploy changelog. Changes in bundles are tracked in their own changelog.md file. Please keep the Stepup-Deploy changelog up to date during development add all noteworthy change notes or upgrade instructions to this file in an 'upcomming release' entry.

• the new release should be tagged either on master or on the release branch when releasing for a specific (non latest) release.

• the tag can be released in Github

Please update the changelog in the branch where the feature/bugfix is developed. When writing the changelog and the next version number is not clear yet, please write the changelog entry and use Upcoming release as the version number.

Building releases

Most of the Stepup and Openconext projects have a built in 'on tag build a new release' Github Actions Workflow. This workflow will use a Docker container to build a tarbal and shasum. For Stepup projects we utilize Stepup-Build. Other projects have their own build scripts (usually a shell script in the projects bin folder). The Workflow will create a new release in the GitHub project. And this release is extended with the tarbal and shasum that was created in the Workflow.

The one remaining manual task is to update the release notes on the Github release page. This can be done using the auto-generate feature of Github, or by copy pasting the changelog entry. Both options are acceptable.