These are the steps required to cut a SystemTap release.

Check the build

Run "make update-po" in a top-level build tree. This may update several po/* files in the source tree. Commit those changes.

Update the AUTHORS file with AUTHORS.sh.

Check the whole source tree for the PRERELEASE marker. Yes, emacs, not vi.

git grep -Oemacs PRERELEASE

Increment Copyright years in messages (session.cxx, staprun/common.c, stapdyn/stapdyn.cxx, stapbpf/stapbpf.cxx) if needed.

Set the productnumber in doc/SystemTap_Beginners_Guide/en-US/Book_Info.xml to match the release number.

Update the documentation in the source tree using "./scripts/update-docs". Also increment Copyright years for any docs that were changed (e.g. doc/SystemTap_Tapset_reference/tapsets.tmpl,dummy-tapsets.xml most likely).

Regenerate the examples index in "testsuite/systemtap.examples".

Make sure that the NEWS file is actually current with the major changes, since this is the best base for forming the release notes.

Run a fuller-than-usual build:

configure --enable-dejazilla --enable-testapps=all
make rpm  # on several OS generations, for dependency/build-tool differences
make all install
sudo make installcheck

The testapps part is especially important if sys/sdt.h changed from the last version, since other applications compile against that now. Regressions in compilability / performance in these sdt.h client apps should be avoided.

The remote functionality requires a bit of manual setup for testing, as for each host you must have both an automated ssh connection (e.g. via kerberos or ssh pubkeys) and an appropriate build environment, locally or using a compile server. With those conditions met, you can run an installcheck with TESTREMOTES as a comma-delimited list of hosts, e.g. "make installcheck RUNTESTFLAGS=remote.exp TESTREMOTES=foo,bar,baz"

The interactive systemtap container image should be updated as well. To do this run:

stap-jupyter-container --build
stap-jupyter-container --publish

Note: You must have write access to quay.io/systemtap/isystemtap

Compile the release notes

It's easiest to get a template for the notes starting from previous SystemTapReleases. Here are the major sections to fill in:

Create the release in git

Check that the configure and .spec files have the correct version number. The .spec should also have an appropriate %changelog entry with the current date, and a link to the SystemTapReleases wiki page (so people can find/read the release notes based on the rpm %changelog.) Add the release date to the top of NEWS.

Tag the tree with "git tag -s release-X.Y". The "-s" signs the tag with your GPG key, which should be signed by at least one of the previous maintainers to keep up the "web of trust." (*Need some notes on where/when this signing is to be done.*)

Create the final source archive with "make dist-gzip", and sign it: gpg --armor -b systemtap-X.Y.tar.gz, which will result in a .asc file.

Get the public sources in order. Use a normal "git push" to update the public git HEAD, and then send the tag with "git push origin release-X.Y". Then upload the source archive and its signature with scp to "sourceware.org:/sourceware/ftp/anonftp/pub/systemtap/releases/".

If something goes dramatically wrong with building this tarball during your own or fedora builds, it will be necessary to create a new minor version tag, tarball, and perhaps a mini-release-note.

Build the Fedora package

Upstream docs: https://fedoraproject.org/wiki/Using_Fedora_GIT, http://fedoraproject.org/wiki/Package_update_HOWTO.

Upload the source archive you create from dist-gzip with "fedpkg new-sources /path/to/systemtap-X.Y.tar.gz", which will also update ".gitignore" and "sources". Copy systemtap.spec from the git source tree. Consider merging fedora-only changes committed to the tree. Now run "fedpkg local" to test the rpm build locally. If this succeeds, you're ready to create the official build. If it fails, and a minor fedora-only spec-file patch makes it go, make it so. If something systemic is wrong requiring a source tarball respin, see above about a new tag, etc.

Use "fedpkg ci; fedpkg push" to commit "sources", ".gitignore", and "systemtap.spec" to the fedora repository. If there are any patches from a Fedora minor update (which are hopefully in this new upstream release already), remove then from git too. Finally run "fedpkg build" to submit the build to koji.

Once the devel build is successful (or while it's running if you're feeling brave), "fedpkg switch-branch" to one of the release-track fedoras. Run "git merge devel" to do all the equivalent of what you did for devel. "fedpkg ci; fedpkg tag; fedpkg push; fedpkg build".

In each release-track branch "fedpkg update" must be run to submit the package to bodhi once the build is finished. (You don't have to run "fedpkg update" for rawhide, since packages there get pushed automatically.)

Special case: Fedora minor updates

Sometimes we want to update the Fedora packages without bothering with a full SystemTap release. In this case we shouldn't have to do new-sources; we can just provide a patch file and bump the spec accordingly. First, increase the number in the "Release:" header. Then add a new "PatchN: my-update.patch" line for each new patch with a unique number N. Apply each patch in the "%prep" section with "%patchN -p1". Finally, add an entry to the "%changelog" explaining the reason for patching, and proceed to test-tag-build as normal.

Push it out and announce it

Piece of cake, right? Now all that's left is to tell the world!

Regenerate the documentation on the sourceware web site using "./scripts/update-htmldocs".

Recheck the release notes one last time, in case of any last-minute closed PRs, added samples, NEWS blurbs, new AUTHORS. Next send out the release notes to systemtap@sourceware.org , and CC linux-kernel@vger.kernel.org and lwn@lwn.net , with a format-preserving mailer. Watch out for word-wrap.

Update SystemTapReleases for the new version with links to the source archive, the git tag, and the archived release notes. Also update the version number on HomePage. If you like, you can update our Wikipedia page with the new version number too.

Formally begin the next release's development cycle by bumping the version numbers. The following files need to be updated to the next version:

Save those changes and run autoconf. If autoconf gives errors about mismatched versions, then you may need to run autoreconf instead.

None: SystemTapReleaseGuide (last edited 2023-05-01 12:40:00 by MarkWielaard)