-
Notifications
You must be signed in to change notification settings - Fork 202
How to Be a Release Manager
Release Managers are responsible for a specific feature release (see Developing CUPS). Each of the currently planned feature releases has an assigned Release Manager, and any regular contributor to/developer for CUPS can volunteer to be a Release Manager.
Most feature releases are developed over one year and maintained for one year, so any potential Release Manager should plan on a two year time commitment.
A Release Manager's responsibilities are:
- Management of a feature release ("vM.N") milestone in Github
- Coordination with/coaching of developers for bug fixes and features
- Coordination with other Release Managers for bug fixes
- Monitoring of CI builds
- Creation of release tarballs and announcements as needed
A release manager's job is not to do all of the coding!
The Github Actions page shows the results of several CI tools and the CUPS test suites that are run for every pushed change. These are also run for pull requests and can sometimes reveal platform-specific issues in code changes.
Note: Before doing a release, make sure that all of the Github Actions CI tasks are passing.
To do a release you'll need a GPG key for your primary contact address and a Mac or Linux system with the GPG software installed on it. The CUPS source repository contains a script called makesrcdist that is responsible for creating the release tarball, signing it, and pushing a tag to Github for the release. For example, to release 2.4b1, run the following command:
scripts/makesrcdist 2.4b1
The script checks first that the version number you are using matches the version numbers in the various documentation, autoconf, and header files, and then should report:
Creating tag for release...
... git output ...
Exporting v2.4b1...
Preparing files...
Archiving...
Compressing...
Signing...
Done - files in /path/to/home/directory.
You'll then find the following files in your home directory:
cups-v2.4b1-source.tar.gz (source archive)
cups-v2.4b1-source.tar.gz.sig (detached GPG signature)
Next you need to go to the Github repository page and edit the newly created tag. Attach the two files from your home directory and add a description with a list of the entries from the CHANGES.md for this release. Make a copy of the description text because you'll also need it to publish the release news on the OpenPrinting web site. For example:
CUPS v2.4b1 adds this cool thing and that cool thing along with a boatload of bug fixes. Changes include:
- Change one
- Change two
...
Enjoy!
Once you have saved these changes, create a post on the OpenPrinting organization site in the _posts directory. For example, if v2.4b1 is released on October 22, 2021 you will create a file named 2021-10-22-cups-2.4b1.md containing the following:
---
title: CUPS 2.4b1
layout: single
author: YourName
excerpt: CUPS v2.4b1 adds this cool thing and that cool thing along with a boatload of bug fixes.
---
CUPS v2.4b1 adds this cool thing and that cool thing along with a boatload of bug fixes. Changes include:
- Change one
- Change two
...
Enjoy!
Finally, send an email to the printing-architecture mailing list announcing the release, again with the same text you used for the Git release description.