Skip to content

RELEASE.md

Latest commit

 

History

History
61 lines (44 loc) · 3.74 KB

RELEASE.md

File metadata and controls

61 lines (44 loc) · 3.74 KB
Raw

Release Process

Between Releases

Various CI features have been implemented to ease the release process, but some parts of it are still intended to be manual (e.g., each CHANGELOG for each individual crate should be written by hand prior to release). We subscribe to the philosophy outlined on the keepachangelog site. The short version is that (almost) every PR should include a manually written entry to one or more CHANGELOGs in the repository under the ## Unreleased header.

Time to Release!

Before cutting a release, review every entry under ## Unreleased in each CHANGELOG.md and verify that every item links to its originating pull request.

The following steps are handled automatically by the release-plz workflow. In the event it fails, they can be performed manually.

Manual release steps

  1. Go through each publishable crate (i.e., each wdl-* crate, wdl, and sprocket) and increment the version in Cargo.toml (as well as match any internal dependency versions that need to be bumped).

  2. Update each CHANGELOG.md file with a new release header.

  3. Create a new tag for each new crate version excluding sprocket, with the format {CRATE_NAME}-v{VERSION} (where VERSION matches the latest version in the root Cargo.toml)

    • For new sprocket releases, the tag name format is v{VERSION}
    git tag {CRATE_NAME}-v{VERSION}
git push --tags

  4. Publish each crate to crates.io

    cargo publish --workspace

  5. If updating sprocket, create a new GitHub release with the title v{VERSION} and mark it as the latest release

The body of the sprocket GitHub releases must be updated manually, regardless of the success of the release-plz workflow. By default, the release will only include the changelog of the sprocket crate. Each crate's most recent CHANGELOG entries should be copy and pasted into the release notes. These should be ordered with sprocket first, followed by the remaining crates topologically (starting with wdl-grammar).

Note that the individual CHANGELOG.md files hard-wrap lines at ~80 columns. The GitHub release body should not hard-wrap lines—each bullet point should be a single unwrapped line so that it renders cleanly on GitHub.

Format each section so that it looks like:

### `<crate name>`

<copy and pasted CHANGELOG entries>

Post-Release

After the release is complete, the following tasks should be performed. For each downstream repository, read its RELEASE.md before starting—the steps may have changed since the last release.