Skip to main content

Release

Release Process

Release flow, validation, and publication details for OPSd CLI.

Release Process

This page describes the public release flow for OPSd CLI.

Release Overview

OPSd CLI releases are versioned with git tags in the form vX.Y.Z.

Each release should publish:

  • a portable CLI bundle
  • an asdf install path
  • a docs snapshot for the same tag

What Gets Updated

Before tagging a release, update:

  • lib/opsd/version.rb
  • CHANGELOG.md
  • release-facing wording in README.md, SUPPORT.md, SECURITY.md, and CONTRIBUTING.md

Release Sequence

Use this sequence for a normal versioned release:

  1. Confirm the release scope and target version.
  2. Update lib/opsd/version.rb to the new version.
  3. Update CHANGELOG.md with a short summary of what changed.
  4. Run the unit test suite.
  5. Create the git tag vX.Y.Z on the release commit.
  6. Let CI build and publish the release artifacts.
  7. Verify the published bundle and install smoke.
  8. Confirm the docs snapshot asset was published for the same tag.
  9. Mirror any important release note on the website if public-facing messaging needs to stay aligned.

Validation

Release validation should confirm:

  • bin/opsd version
  • portable bundle build
  • checksum generation
  • asdf install smoke
  • shell completion smoke

The CI pipeline already covers these checks in the release jobs, so the main goal before tagging is to make sure the release commit is ready for those jobs to run cleanly.

After Release

After the tag is published:

  • confirm the GitLab Release exists
  • confirm the assets download correctly
  • confirm asdf install opsd <version> works from the release bundle
  • confirm the website or release notes reference the same version

The website can also consume the tagged docs snapshot asset directly so the published docs match the release tag rather than the default branch.