Skip to content

Release Management

Jump to bottom
Dr. Martin Brumm edited this page Mar 31, 2021 · 4 revisions

Release Management

We use semantic versioning for our releases. This is represented by the dotted version numbers: #major.#minor.#maintenance.

Repository Setup

The git repository is laid out like this:

  • branches:
    • master - All development happens here. Pull-requests should be made against master
    • x.y - Maintenance branches for tracking bugfixes
    • your_feature_branch - topic branches for features that are under development
  • tags:
    • releases/x.y.z - Tags representing each release.

Release Process

  1. Create a tag named releases/x.y.z where x.y.z is the version number being released.
  2. GitHub Actions will trigger based upon the tag name and create the release.
  3. Edit the generated release document to include the changelogs, release notes, etc.
  4. If this is a ".0" release, create a maintenance branch. (e.g. If we're releasing 1.0.0 or 1.2.0, create a branch named 1.0 or 1.2, respectively.

Maintenance Releases

Maintenance releases require some extra steps because we need to ensure that changes we ship with the maintenance release are also included with the main development branch. With Git, there are two ways to do it that are roughly equivalent - merging or cherry-picking.

Merging method

  1. PRs with bugfixes are created against the maintenance branch and merged.
  2. A new tag releases/x.y.z is created against the maintenance branch, x.y, triggering GitHub Actions to create the release.
  3. Edit the release document to include the changelogs, release notes, etc.
  4. Merge the maintenance branch into master.

Cherry-pick method

  1. PRs with bugfixes are created against master, as normal.
  2. Commits merged into master are then cherry-picked into the maintenance branch.
  3. A new tag releases/x.y.z is created against the maintenance branch, x.y, triggering GitHub Actions to create the release.
  4. Edit the release document to include the changelogs, release notes, etc.

Additional Information

  • Change the Readme.md and Changelog.md with the appropriate information.
  • change the Version in settings.gradle
  • Go to the release on github Rails Release on Github
  • Edit any necessary information.
  • Download the created release packages.
  • Followup on sourceforge:
    • Create a new folder with the appropriate name corresponding to your release.
    • Upload the files from above into that folder.
    • After the upload has finished klick on the i symbol and link the appropriate usage information (which plattform that file is suitable for).
Clone this wiki locally