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.

Time Commitment

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.

Responsibilities

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
• Coordination, announcements and merging fixes for security vulnerabilities
• 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!

Monitoring Github Actions

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.

Prerequisites for doing a release

• all of the Github Actions CI tasks have to be passing
• update makesrcdist script if needed

Updating makesrcdist script

If you are doing a new major or minor release, you need to update printf argument of cupsversion variable in makesrcdist script.

For example for 2.4b1/2.4.x:

printf "2.04%02d" $cupsversionpatch

or for 3.0.0:

printf "3.00%02d" $cupsversionpatch

Doing a Release

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 (README.md, CHANGES.md), autoconf (run autoconf -f after you make changes in configure.ac), and header files (cups/cups.h, vcnet/config.h, vcnet/libcups2_native.nuspec, vcnet/libcups2_native.redist.nuspec, xcode/config.h), 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!

* <a href="https://github.com/OpenPrinting/cups/releases/tag/v2.b1" itemprop="sameAs" rel="nofollow noopener noreferrer"><i class="fas fa-fw fa-download" aria-hidden="true"></i>Download v2.4b1</a>

And when creating your first entry in _posts do not forget to add your author info to _data/authors.yml and a picture of you into assets/images/ (link the image in _data/authors.yml). So people reading your release announcement know who you are.

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.

Handling security vulnerabilities

In case reporting of security vulnerabilities is not available on the repository (it should be available under New issue at Issues tab), repository admin (admin of OpenPrinting group on GitHub - Till Kamppeter) or anyone with sufficient permissions in OpenPrinting Github has to enable Security advisories and Private vulnerability reporting at tab Security on the Github project repository.

Once there is a security advisory reported, coordinate discussion among OpenPrinting CUPS security team members (don't forget to add OpenPrinting/security group as a collaborator) - whether it is a security issue and agree on the fix. The fix will be available in private CUPS Github repo - anyone who wants to clone it and work on the patch has to be added into list Collaborators on the page's right.

If there is an agreement about the issue and the fix:

• accept the advisory and request CVE number from GitHub via buttons on the advisory's page,
• push the fix into a branch in the private repository,
• agree with others in OpenPrinting CUPS group on the date when you send email to [email protected] and when the public date and time of the vulnerability will be - public disclosure has to be around 7-10 days after the email is to the mailing list.

Once we agree on sending email date and public date+time, send email to [email protected] with the following structure:

• subject has to begin with four characters '[vs]' to pass the mailing list spam filter,
• subject has to contain the assigned CVE number, project name and short vulnerability summary, f.e. - EMBARGOED CVE-2023-32324 cups: heap buffer overflow in cupsd,
• the body has to contain the data from the first advisory comment - severity, description, reproducer, PoC, impact and the proposed public disclosure date+time,
• attach the patch fixing the issue.

After public disclosure time passes:

• publish the advisory via its GitHub page - there is Publish advisory button on the advisory's page,
• merge the advisory into master branch and into any other supported branches, which are affected by vulnerability - mention the CVE number in the commits,
• send almost the same email which you've sent to [email protected], but send it to [email protected] without public date, without [vs] in the subject and without any mention of embargo, but with link to the merged fix,
• (optional) release a new version with the fix if the project is in state which can be shipped.