ReleaseProcess

Release Process

We are using the Cockpituous continuous delivery tools for Cockpit. Contact Stef or Martin for help if you need to use it or something broke with it.

We release every other Wednesday, at the end of each agile Sprint. Detailled release procedure:

1. Issues and PRs that are urgent for the next release should have a release-blocker label. Review the list, and ask team members if they still have anything for the current release.

2. Find out the previous release: PREV=$(git describe --abbrev=0 --tags); echo $PREV

3. Look at the list of closed issues with the release-note label for likely inclusions into the release notes. Review the changes since the previous release with git shortlog $PREV.. and pick out other noteworthy bits. Stick to new features and ignore changes to bots/, tests, non-critical bug fixes.

4. From that, draft a new release note blog post on the cockpit-project.org repo in a pull request (from your own forked repo). Describe user-visible changes from a user's (not developer's) point of view. Include screencasts, screenshots, and thank external contributors. Use the master branch in your repository, then you get an automatically rendered page once you enable GitHub pages for your cloned repo. Remove the release-note label as you include items in the notes.

   As an example, look at the release notes of Cockpit 169 (with a video) which was done in PR #177, or Cockpit 171 (with external contributions) which was done in PR #185. Both PRs refer to the preview page.

   Let some native English speaker review the blog post for correct spelling, grammar, and legibility. Usually Garrett and Allison. Ask them to start reviewing the headings first (as that blocks the next step), and the contents later.

5. Make sure you have your GPG added and verified in your GitHub profile so that the release actually appears as signed.

6. The headings of the release notes become the "release news" summary which appears on the GitHub release page and downstream package changelogs. They are taken from the signed release tag.

   Create that tag with: git tag -s $((PREV + 1)). As the tag description, use the format as documented in cockpituous release:

   123
   
   - Add this cool new feature
   - Support Python 3
   - Fix wrong color on the bikeshed
   

   Push it to cockpit's master: git push origin $((PREV + 1)) (you might use a different origin name).

7. This should trigger cockpituous release through the release webhook, which will call cockpituous' release-runner on cockpit's release script. This is a running pod on CentOS CI. It will inform about the release on IRC in #cockpit, and you can follow the release log on fedorapeople.org (link is in the IRC notification). If it does not start, or fails, ask Martin or Stef for troubleshooting.

   Depending on how loaded the Fedora koji and COPR builders are, this can easily take an hour or two.

8. Verify that the new version is:

   • current and verified on the GitHub project release page
   • built in COPR
   • built on Dockerhub into a current cockit/ws container
   • current on the cockpit documentation site.
   • present on Fedora bodhi for testing and landing.

9. Land the pull request for the release announcement.

10. Create a textual release announcement and send it to [email protected] and CC: [email protected]. Also BCC: three Red Hat internal mailing lists (ask Martin or Stef about these).

    Use the header, footer, and formatting like in the Cockpit 174 announcement.

11. Ask Martin to upload the new release to Debian. This step is not currently automated.

12. Test the packages on bodhi on your machine:

    alias kojiget='koji download-build --arch=noarch --arch=x86_64'
    kojiget cockpit-172-1.fc28
    rpm --freshen --verbose *.rpm

    Make sure the update works, go through all the pages in Cockpit (make sure you disable your `~/.local/share/cockpit for this!), and report back on bodhi with a +1. After getting enough karma (usually after a day or two), the package should automatically be pushed to stable.