The following sections describe how to release Minishift.


  • You must have a GitHub personal access token defined in your environment as GITHUB_ACCESS_TOKEN.

  • You need gnutar installed on your machine. See also GitHub issue #657.

Preparing the GitHub Milestone

  1. Verify the milestone you want to release:

    • Move remaining open issues into the next milestone.

    • Review resolved/closed issues and make sure they are classified correctly.

    • Check and update the resolution of the issues. For example, issues with a merged pull requests should be labeled as resolution/done.

  2. Close milestone.

Cutting the Release

  1. Bump the Minishift version in the Makefile.

  2. Commit and push your changes with a message of the form cut v1.0.0.

  3. Create binaries and upload them to GitHub (this will also tag the release):

    $ make release
  4. Trigger the documentation build.

    $ export API_KEY=<api-key>
    $ curl -H "$(curl --user minishift:$API_KEY 'https://ci.centos.org//crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)')" -X POST https://ci.centos.org/job/minishift-docs/build --user "minishift:$API_KEY"

    This will build minishift-adoc.tar, which will be consumed by docs.openshift.org during the next nightly build. For more information, see Writing and Publishing Minishift Documentation.

Post-Release Tasks

As part of the release process we also send a release announcement and edit the GitHub release page.

For the latter we usually add a categorized list of closed issues as well as some release highlights (most often taken from the release announcement).

If you have jq installed on your machine, you can use the issue-list.sh script to generate the markdown needed for adding the issue list. For example:

$ cd scripts/release
$ ./issue-list.sh -r minishift -m 9