Making a New Release

This covers the process of making a new release.

First, run some checks locally (though it's not really necessary since CI will do these anyway).

Build package, docs, and check dependencies

  make build-all

Check dependencies

  make check-deps

Before Merging Your Changes

Immediately Before Merge

1. Do you need to add version exceptions? Now is the right time to do that.
2. Are there any custom release steps to go through for your PR, which may be captured in a pre-merge checklist?

Well Before Merge

1. If there are backwards incompatibilities, announce a migration plan and also document it in the draft Release Notes.
2. Ask concerned parties to test dependent packages to ensure they are still OK.

Cutting a New Release (After Merge)

Bump the version in info.rkt and make a fresh commit

  (define version "i.j.k") ; numbers corresponding to major.minor.patch

Tag the release commit

$ git tag -n<NUM>  # list existing tags and annotations; if specified, NUM configures verbosity
$ git tag -a <new version number> -m "<release message>"  # or leave out -m to enter it in Vim

Push the changes including the new tag to origin

$ git push --follow-tags  # push new tag to remote

Monitoring the Release

In case of any issues following release, consult the Package Build Results page as it may contain more specific information.

Immediately afterwards

After releasing the new version, keep an eye on the package server for around half an hour to see if there are any build failures or conflicts reported there. CI workflows can only test that the code is internally consistent and working correctly, but on the package server, there are also interactions with other packages in the global collection namespace.

The next day

If there are no issues, check again in about 24 hours to make sure, as that is the cadence of the full documentation refresh cycle.

Verify that the package docs are visible on the Racket Documentation Server.