This document explains how to make a release of the Checker Framework and the Annotation File Utilities. The process takes around 2 hours (including manual steps) when all goes according to plan. However, the lengthiest steps are automatic so you will be able to work on other tasks.

Note: If you have never read this document before, please read the section Pre-release Checklist first. It is also recommended that you read sections Release Process Overview and Changelog Guidelines to familiarize yourself with the process.


Step by Step

More information about the steps is provided in the code comments of the main() functions of the release_build and release_push scripts. Please read those comments if you have never done so before.

Answering 'no' to a prompt does not exit the script unless otherwise indicated.

Be sure to carefully read all instructions on the command-line before answering 'yes' to a prompt. This is because the scripts do not ask you to say 'yes' after each step, so you may miss a step if you only read the paragraph asking you to say 'yes'.

  1. If you have never made a release before, follow the instructions in the Pre-release Checklist.
  2. Update stubparser. If there has been a JavaParser release since the last Checker Framework release, update Stubparser from JavaParser. Do this on your own computer; it doesn't have to be done on the CSE file system..
  3. On your own computer, update the Checker Framework source code in the master branch:
    • Update the AWS Java SDK BOM dependency. In file checker/build.gradle, edit the com.amazonaws:aws-java-sdk-bom dependency to be the latest version number at (The next time Dependabot opens a pull request for that dependency, you might need to respond @dependabot ignore this dependency to prevent such pull requests for the next month.)
    • Update AFU and Checker Framework change logs by following the instructions at content guidelines.
    • Update the Checker Framework version number in checker-framework/build.gradle, in the allprojects block. (The AFU version is updated as part of the release scripts.)

      Update the minor version (middle number in the version number) if there are any incompatibilities with the previous version. This includes incompatibilities for people who are maintaining a checker, which happens if the signature changes for any method in these classes:


      (TODO: Write a command that diffs these classes between the previous and current release.)

      A rule of thumb is that any framework change that requires changes to more than one type-checker should be at least a minor version (middle number in the version number) bump.

    • Update the Annotation Tools version number, again in the master branch, in annotation-file-utilities/build.gradle. (TODO: Are any other replacements necessary?)
    • Commit and push these changes to typetools/master.
  4. Log into a machine on the CSE file system, such as tern.
    ssh $
  5. In a user-specific temporary directory, clone/update the Checker Framework repository (it contains the release scripts).
    mkdir -p /scratch/$USER/cf-release
    chown -R types_www /scratch/$USER/cf-release
    chmod -R g+rw /scratch/$USER/cf-release
    cd /scratch/$USER/cf-release
    test -d checker-framework && (cd checker-framework && git pull --ff-only --quiet) || git clone --quiet
    cd checker-framework/docs/developer/release
    (The release scripts will checkout and build all dependencies.)
  6. Run release_build to create the release artifacts and place them in the development website
    git pull && python3 all

    For verbose debugging output, use the --debug option.

    Note: The "all" argument specifies that all projects should be built. There has been some work done in order to select only specific projects (AFU and Checker Framework) to be built but more work still needs to be done. Just pass "all" for now.
  7. Run release_push to run a few tests and move release artifacts from the development website to the live site and to Maven Central
    python3 release

    Note: The "release" argument states that you intend to do an actual release. If you just want to test the script, leave out "release" and the script will run but not update anything.
    If you get an obscure error about permissions, try running the release_push script several times in a row. This will sometimes update the repository permissions such that the script can proceed further each time.
  8. Update list of qualifiers in Project Lombok. Follow the instructions in If the release did not add, remove, or rename any type qualifiers, no changes are required. Those instructions do not work on macOS, so you may need to use a Linux machine to make the changes.
  9. Update the Annotation Tools' use of the Checker Framework by making a pull request that changes two occurrences of the old version number in annotation-file-utilities/build.gradle.
  10. Make Daikon use the latest Checker Framework version. Follow the instructions in java/lib/README to update the Checker Framework version number in Daikon.

Continuous integration tests

The following continuous integration tests should all pass before you make changes that you need to test. If not, notify the relevant team members. Refresh this page to see the latest status.

  • Annotation File Utilities: Azure Pipelines typetools/annotation-tools status
  • Checker Framework: Azure Pipelines typetools/checker-framework status
  • JDK: Azure Pipelines typetools/jdk17u status
  • Daikon: codespecs/daikon Azure Pipelines status

Deploy to local Maven repository

To deploy to a local Maven repository, run ./gradlew PublishToMavenLocal in checker-framework.

Then, update your project's buildfile. For Maven, just update the Checker Framework version number. For Gradle, also add repositories { mavenLocal() }.

Often, the version number in checker-framework/build.gradle (in allprojects { version ... }) will end in -SNAPSHOT, but this is not a requirement. Regardless of the version number, beware that you may get different results than on other computers that have not deployed the same commit of the Checker Framework to their local Maven repository.

Snapshot release

To release the Maven artifacts to the Maven Central snapshot repository:

  1. Ensure that ~/.gradle/ includes your user token in SONATYPE_NEXUS_USERNAME and your user token key in SONATYPE_NEXUS_PASSWORD.
  2. Ensure that the version number in checker-framework/build.gradle (in allprojects { version ... }) ends in -SNAPSHOT.
  3. Run ./gradlew publish in checker-framework.

Using a snapshot release

Gradle Groovy (build.gradle file)

In the build.gradle file of a project that you want to use the snapshot version of the Checker Framework:
repositories {
  maven { url '' }

ext.checkerFrameworkVersion = '3.28.1-SNAPSHOT'
dependencies {
  compileOnly "org.checkerframework:checker-qual:${checkerFrameworkVersion}"
  testCompileOnly "org.checkerframework:checker-qual:${checkerFrameworkVersion}"
  checkerFramework "org.checkerframework:checker:${checkerFrameworkVersion}"
configurations.all {
  resolutionStrategy.cacheChangingModulesFor 0, 'seconds'

Gradle Kotlin (build.gradle.kts file)

In the build.gradle.kts file of a project that you want to use the snapshot version of the Checker Framework:
val checkerFrameworkVersion = "3.41.1-SNAPSHOT"
dependencies {
   resolutionStrategy.cacheChangingModulesFor(0, "seconds")

Maven (pom.xml file)

In the pom.xml file of a project that you want to use the snapshot version of the Checker Framework:

Pre-release Checklist

If you have not performed a release before you must follow these steps.

1. Ensure you are a member of the types_www and pl_gang groups
Run the command "groups" on the CSE file system (perhaps on tern). If the group types_www or pl_gang do not appear in the list, email the appropriate person to be added (currently Michael Ernst).
2. Import the Checker Framework signing key for PGP
SSH into tern and run the following command:
gpg --allow-secret-key-import --import /projects/swlab1/checker-framework/hosting-info/release-private.key

Note: The password for this key is located in the file
and is used by the release_push script to sign Maven artifacts.
3. Sign up for a Sonatype Account
You will likely want to do this a few days in advance. Directions can be found here. Remember to be asked to be added to the org.checkerframework repository by creating a ticket (see the note here). If after signing up for a Sonatype JIRA account you are not able to sign in to to create a ticket, there may be a configuration problem with your account. In that case, sign up for a second Sonatype account, and use that account to file a ticket indicating that you cannot sign in with your first account.
4. Add your user token information to gradle/ in your home directory.
Follow the instructions to generate a user token. Create a ~/.gradle/ file with the following:
Since the file contains your password, make it non-readable: chmod og-rw ~/.gradle/
5. Get edit privileges for Checker Framework, Annotation Tools
Once a release has been completed, you will be prompted to update issues in the issue tracker for each project that has been released. You will need to be a "developer" for each project so that you have update privileges for the issue trackers. You should be listed as a member of typetools as a committer on GitHub.
6. Install html5validator
If you are going to perform the release on tern, you may need to install html5validator. If html5validator --version issues any errors, try running pip3 install --user html5validator. You may need to add .local/bin to your path.
7. Add GitHub SSH keys to tern
See GitHub docs.
8. Configure git
git config --global "Your Name"
git config --global
or copy over your configuration file.
9. Run release_build once
To save time on release day addressing potential configuration issues, before your first release day, ensure that release_build is working correctly by following the initial steps of the Step by Step section. release_build still needs to be re-run on release day (even if no changes were pushed to any repositories since the last run of release_build) in order for the release date to be correct in all documents.

Release Process Overview

This section first explains the structure of the projects on disk on tern, then lists scripts used during the release process.

File Layout

Release Directory
/scratch/$USER/cf-release Contains repositories and scripts to perform a release
build Contains repositories for: annotation-tools, checker-framework, git-scripts, plume-bib, plume-scripts
These repositories are used to build the Checker Framework and its dependencies.
interm Contains repositories for: annotation-tools, checker-framework, git-scripts, plume-bib, plume-scripts
The repositories in build are clones of repositories in interm. The repositories in interm are clones of the GitHub repositories. This is so that we can test and push the release to the interm repositories then check the release before we have made any irreversible changes. Then, when the release is validated, all we do is run "git push" on all of the repos in interm.
sanity Directory used by the release_push script to do sanity checks.
checker-framework/docs/developer/release The directory where the release scripts are run from. Any changes made under this directory won't be automatically committed when the release is committed.
Live Website Directory
/cse/www2/types The file system location of the website:
m2-repo The location of the in-house Maven repository. It is accessed through URL:
Staging (Development) Website Directory
/cse/www2/types/dev The file system location of the development staging website:
<project>/current The staging analogue to /cse/www2/types/<project>/current directory. The latest release is copied from this directory to the /cse/www2/types/<project>/current by the release_push script after a prompt.
m2-repo The location of the in-house staging version of the Maven repository. It is accessed through URL:

Release Scripts

As mentioned above, in order to release the Checker Framework you must run two scripts, and but there are supporting scripts and files in the release directory. Some of these files are described below. Reverts the build/interm repositories to the state of their master repositories in GitHub. It then builds the projects and all their artifacts and then stages a development version of all websites to This script is thoroughly documented in code comments located in its main() function. Verifies the release at is correct through scripts and manual steps. When the user is satisfied the website is correct it deploys the website to the live website: It also pushes Maven artifacts to Maven central. This script is thoroughly documented in code comments located in its main() function. Utility methods used in both release_push and release_build. Contains methods to run various sanity checks. These methods are called from Global variables used in release_push, release_build, and sanity_checks. These should NOT be used in release_utils as release_utils is supposed to consist of self-contained reusable methods. These variables are tailored for running the scripts on
release.xml The previous release script used Ant to do a number of tasks. Rather than reimplement them all, we still use the targets from this script. They are called from release_push and release_build.

Changelog Guidelines

Each developer is responsible for updating project changelogs to reflect changes they have made each month. The changelogs should be updated by "feature freeze" though at the latest this should be done before "code freeze". Before releasing, the person performing the release will be asked to verify the changelogs. Please check that there aren't typos (i.e. missing release date/version information, spelling errors, etc...). Also check that the changelog obeys the guidelines below.

Content Guidelines

  • Only (and all) changes that affect users (including type system developers) go into the changelog. If a change is breaking, no matter how small, mention it.
  • Even if some code has been committed to the repository, don't announce the feature until it has been documented in the manual.
  • Checker Framework:
    • List all issues (in issue trackers) resolved since the previous release: previous release, issues query, current changelog.
    • Ensure the changelogs reflect version control commits since the last release, via the command line:
      cd $CHECKERFRAMEWORK && git log --name-status `git describe --abbrev=0 --tags`..
      or via GitHub Checker Framework commit logs.
    • Ensure the changelogs reflect changes to the manual since the last release, via the command line:
      cd $CHECKERFRAMEWORK && git diff -w `git describe --abbrev=0 --tags` docs/manual
  • Annotation File Utilities:
    • List all issues (in issue trackers) resolved since the previous release: previous release, issues query, current changelog
    • Ensure the changelogs reflect version control commits since the last release, via the command line:
      cd $CHECKERFRAMEWORK/../annotation-tools && git log --name-status `git describe --abbrev=0 --tags`..
      or via GitHub Annotation File Utilities commit logs.
    • Ensure the changelogs reflect changes to the manual since the last release, via the command line:
      cd $CHECKERFRAMEWORK/../annotation-tools && git diff -w `git describe --abbrev=0 --tags` annotation-file-utilities/annotation-file-utilities.html

Style Guidelines

  • Changes are written from the user's perspective. Don't include implementation details that users don't care about.
  • To be consistent, write in the past tense (e.g. "Added option for verbose error messages").
  • Lines should not exceed 80 characters wide.
  • Break the different programs into their own sections. See notes on release 1.7.0 and 1.5.0 for an example. Tools should have their own section within the Checker Framework release notes (excluding issue fixes from the issue tracker).
  • Be specific. Don't write something like "added a few options to Eclipse plugin". Do write "added options to the Eclipse plugin to include stub files, ignore warnings, and show verbose output."

Backing Out an Uncommitted Release

At the time of this writing, there are 2 steps that cannot be reverted.

  1. The push from the interm repositories to the GitHub (release) repositories
  2. The release of the staged Maven artifacts

If you have executed either of these steps and then realized there is a breaking error, you should do another release. The release script will allow you to do a point release like "" when a version "1.8.0" already exists.

If you have NOT committed an irreversible step then you can follow the steps below to point the live release to a previous release. You can then redo the original release. Make sure to say "yes" when the release script asks you to delete the old directories.

Manual Steps to Back Out a Release

Note: You may find yourself copying release directories for some reason or other. It is important to remember that the symlinks may be absolute. You should check any symlinks that may be affected by the move and ensure they point to the new location and not the old one.

Future Improvements

Below is a roughly priority-ordered list of future improvements. In a perfect world we would do all of these. At the moment, I believe only the first 2 (Open JDK Javadoc Fixes, and More Sanity Checks) should have any appreciable priority.

More Sanity Checks

There are likely more sanity checks we might want to run during the release process. One such example would be running the tutorial from the command line.


  • Implement one of the sanity checks mentioned in this section.
  • Add your sanity check to the appropriate location in the release_push script.
  • Update this document to reflect the new steps.

Sanity Checks:

  • Run tutorial sanity check automatically via command line.

Release in Continuous Integration

If we could run the release_build script nightly, we could head off broken links and other release related errors.


  • Create a tern task to run the release_build script without prompting.
  • Observe the output of this task and identify possible errors.
  • Fix up all observed errors until the release_build script runs without error.
  • We probably want to move the link checking of the development site to the release_build script and write it out to disk. This will allow the developer releasing the framework to consult pre-made link-checking results rather than waiting for the link checker to execute in the push script.

Auto-copy Release Scripts

The first step in running the release process, after the pre-release checklist, is to copy the release scripts into the cf-release directory. We could automate this.


  • Create a read-only script in cf-release/scripts.
  • Edit the script so that it downloads all release scripts into the cf-release directory.
  • Update this document to reflect this new process.

Option Parsing

There is currently some primitive option parsing written into the release scripts. We should use Python's built-in option parsing library. There are multiple built-in libraries. Please use the latest one.


  • Look up the latest Python parsing library.
  • Replace the option parsing in the and scripts with library calls.

Optional Projects

A user might want to test the release_build script only on a specific project. Some work has gone into the ability to select a project to build. However, this currently doesn't take into consideration of dependencies. It might be more hassle than it's worth to implement this feature. We should either complete the implementation or remove the partial implementation that already exists. See REPL Mode.


  • Improve option parsing to allow the user to select only certain projects to build.
  • Improve scripts to resolve dependencies between projects and only build the selected projects and their dependencies.


The current script is built in an imperative style with little use of object orientation. This improvement would create methods or objects that further encapsulate the current set of steps. We could then provide an easy way to execute these steps from the Python REPL. This would allow the user to execute individual steps in whatever order they saw fit from the Python REPL. This could also be used to automatically back out the current release or the ability to edit/debug the release steps more easily.


  • Further separate the steps of the release process.
  • Provide a default parameterization for these steps to make them easily runnable from the command line.
  • Provide a script to launch Python with these commands on its path.
  • Update this README to document the new functionality.