Skip to content

Release Procedure

Jump to bottom
idhugoid edited this page Feb 1, 2021 · 32 revisions

Release how-to

The mechanics of a release are the following:

  1. [Optional] Check if there are download manager tools updates in the development branch that can be moved into the release branch. The point here is that you can test the new tools while testing as part of this release. Follow the steps in Activating the release

  2. As part of a full release, move any open issues to the next milestone (create the next milestone, if it does not yet exist). Then close the milestone associated with the release.

  3. [Optional] Remove stale or inactive branches from origin.

  4. Merge and Push the development branch into the master branch, check if Github action succeeded.

    git merge development 
    git push

  1. Test the artifacts from the Github actions by downloading each artifact and run/test them in your local machine.

  2. run gulp prep-release from the master branch

    • this will: bump the version number and change the release suffix; push to GitHub.

    • By default, an RC is created. Use --rel option to create a release instead.

    • By default, a patch bump is made. Use --vt minor|major to create minor or major version bumps.

    • Examples:

      • The next command bumps v4.0.1 into v4.0.2-rc
          gulp prep-release
      • The next command bumps v4.0.1-rc into v4.0.1
          gulp prep-release --rel
      • The next command bumps v4.0.1 into v4.1.0
          gulp prep-release --rel --vt minor
      • The next command bumps v4.0.1 into v5.0.0
          gulp prep-release --rel --vt major

  3. bump the version again and change the suffix back to dev; push again.

    gulp prep-new-dev

  1. Merge the master branch into the development branch.

  2. Download the artifacts from the Github actions, prepare zips, and upload to the release page on the GitHub release page. Be sure to type some release notes (see below).

    • The GitHub release page is used to host releases. Creating the release page involves typing the release notes and uploading the binaries. For consistency, please use the Release Page Template for any new release notes. Release notes should draw attention to new features and provide minimal detail about how they are used.

  3. You are done, notify the stakeholders.

Version Numbering

We use semantic versioning: X.Y.Z

  • X: Major versions. Compatibility-breaking changes
  • Y: Minor versions. New functionality; maintains compatibility
  • Z: Patch versions. Bug fixes; maintains compatibility

Labels are used to distinguish between stable releases and unstable development builds:

  • -dev for development versions. Users should avoid these
  • -rc for release candidates. Only 1 built per version
  • Null suffix for releases. Only 1 built per version

The version is set in a few json config files (but use the prep-release gulp task to take care of this). And, of course, the GitHub release page.

Building binaries

The command to build standalone packages is gulp package. It comes in 4 flavours:

  • gulp package-win32 builds Windows binaries (32 and 64 bit)
  • gulp package-darwin builds MacOS binaries (64 bit only)
  • gulp package-linux builds Linux binaries (64 bit only)
  • gulp package-all builds binaries for all 3 platforms.

The Jenkins build server automatically builds packages for the master branch, so you can always grab the latest binaries from: https://build.overture.au.dk/jenkins/job/into-cps-ui/. For releases, it is mandatory to use Jenkins-built packages.

Clone this wiki locally