Skip to content

Release Process

E. Lynette Rayle edited this page Oct 9, 2026 · 9 revisions

1. Clean up dependencies (Removes any packages no longer in use.)

go mod tidy

2. Generate Go documentation to be sure it is correct (optional)

Generate package-level documentation:

go doc ./spdxexp

3. Decide on new version

Gather list of PRs merged since last release. Following Semantic Versioning principles, the rough determination of version change is based on the following criteria.

Update major version if:

  • apps using go-spdx have to make a change to be able to use the new version

Update minor version if:

  • not major
  • includes new feature

Update patch version if:

  • not major or minor
  • dependency updates
  • bug fixes
  • new licenses

4. Update README

  • if changes impact behavior, update README to reflect this
  • update the Go Reference badges to point to the new version

Note

Until pkg.go.dev picks up the new version, the badge will get a message that it doesn't exist. You may have the option to request the newer version.

1. The tag should match the new version and should start with a `v` and  (e.g. v2.7.0)
2. Set title (e.g. Release v2.7.0)
3. Write release notes including sections: ([example](https://github.com/github/spdx-expression/releases/tag/v2.7.0))
    1. Overview - brief description of the primary change(s)
    2. Required Actions for Upgrading - list any steps that are required to update to this version
    3. Details - include a subsection with a description, examples, and other details for each change that impacts usage or functioning
    4. What's Changed - simple list of major changes and link to diff from previous release to this release
4. Publish the release

6. Release to go packages

When the release is published, pkg.go.dev automatically finds the new version. There is a delay, but it will happen.