Fork me on GitHub

Release process

The QA Tools' release process is largely automated by RMT. The configured release process, in this order:

  1. verifies that the working copy is clean;
  2. verifies that the software is in working order by running all tests;
  3. keeps a change log;
  4. creates a new tag according to semver rules;
  5. and published the tag to the Git tracked repository origin.

If any of the verification steps fail, the release process is aborted. These verification steps are there for a very good reason and may never be skipped.

The release build is signed using a separate private key and is managed by Ibuildings. This key can be found in Ibuildings' LastPass and is named "QA Tools private key for releases". Place this key in ./signing-key-release.pem.

Then, to run the release process, execute the following in a terminal:

$ make release

Distributing the release build

After the new tag has been published, the Phar built during the publishing process must be uploaded to the Releases page on GitHub.

  1. Click Draft a new release.
  2. Select the tag you just published.
  3. Use the tag as release title.
  4. If it's an unstable version, indicated by a stability label like #.#.#-beta, tick the pre-release checkbox. Ticking this checkbox does not have any functional consequences for the self-updating process, but functions primarily as documentation.
  5. Copy this release's documented changes (see the change log) into the description field.
  6. Attach the Phar and its public key to the release. You find these in the ./build/release/ directory.
  7. Publish the release.