Skip to content
For Managed AI Platform users, see the cloud platform documentation
Developer documentation > DataRobot CLI > Authentication flow > Release process

Release process

This document describes how to create and publish releases of the DataRobot CLI.

Overview

The project uses GoReleaser for automated releases. Releases are triggered by creating and pushing Git tags, which automatically builds binaries for multiple platforms and publishes them to GitHub.

Prerequisites

  • Write access to the repository
  • All changes merged to the main branch
  • Familiarity with Semantic Versioning

Versioning

We follow Semantic Versioning (SemVer):

  • MAJOR.MINOR.PATCH (e.g., v1.2.3)
  • Pre-releases: v1.2.3-rc.1, v1.2.3-beta.1, v1.2.3-alpha.1

Version guidelines

MAJOR version when making incompatible API changes:

  • Breaking changes to command-line interface
  • Removing commands or flags
  • Changing default behavior that breaks existing workflows

MINOR version when adding functionality in a backward-compatible manner:

  • New commands or subcommands
  • New flags or options
  • New features

PATCH version when making backward-compatible bug fixes:

  • Bug fixes
  • Documentation updates
  • Performance improvements

Creating a release

Step 1: Ensure main branch is ready

# Switch to main branch
git checkout main

# Pull latest changes
git pull origin main

# Verify all tests pass
task test

# Verify linting passes
task lint

Step 2: Determine next version

Review recent changes and decide on the next version number based on SemVer guidelines above.

Step 3: Create and push tag

# Create a new version tag
git tag v0.2.0

# Push the tag to trigger the release
git push origin v0.2.0

Note: The tag must start with v (e.g., v1.0.0, not 1.0.0).

Step 4: Monitor release process

  1. Go to the Actions tab in GitHub
  2. Watch the release workflow run
  3. The workflow will:
  4. Build binaries for multiple platforms (macOS, Linux, Windows)
  5. Run tests
  6. Generate release notes from commit messages
  7. Create a GitHub release
  8. Upload artifacts

Step 5: Verify release

Once the workflow completes:

  1. Go to Releases
  2. Verify the new release appears with:
  3. Correct version number
  4. Generated release notes
  5. Binary artifacts for all platforms
  6. Checksums file

Step 6: Update release notes (optional)

Edit the release notes on GitHub to:

  • Add highlights of major changes
  • Include upgrade instructions if needed
  • Add breaking change warnings
  • Include acknowledgments

Pre-release versions

For testing releases before making them generally available:

# Create a pre-release tag
git tag v0.2.0-rc.1

# Push the tag
git push origin v0.2.0-rc.1

Pre-release versions are marked as "Pre-release" on GitHub and can be used for testing.

Testing the release process

To test the release process without publishing:

# Dry run (builds but doesn't publish)
goreleaser release --snapshot --clean

# Check output in dist/ directory
ls -la dist/

This creates build artifacts locally without creating a GitHub release.

Rollback

If a release has issues:

Delete the tag locally and remotely

# Delete local tag
git tag -d v0.2.0

# Delete remote tag
git push origin :refs/tags/v0.2.0

Delete the GitHub release

  • Go to Releases page
  • Click on the problematic release
  • Click "Delete this release"

Fix the issues and create a new patch release

Release configuration

The release process is configured in goreleaser.yaml. Key configurations:

  • Builds: Defines target platforms and architectures
  • Archives: Creates distribution archives
  • Checksums: Generates checksum files
  • Release notes: Automatic generation from commits
  • Artifacts: Files to include in the release

To validate the configuration:

goreleaser check

Automated release workflow

The GitHub Actions workflow (.github/workflows/release.yml) automatically:

  1. Triggers on tag push matching v*
  2. Checks out the code
  3. Sets up Go environment
  4. Runs GoReleaser
  5. Creates GitHub release
  6. Uploads all artifacts

Best practices

  1. Always test before releasing:
  2. Run full test suite: task test
  3. Run linters: task lint

  4. Build locally: task build

  5. Use meaningful commit messages:

  6. They're used to generate release notes

  7. Follow conventional commit format when possible

  8. Update CHANGELOG.md:

  9. Document significant changes

  10. Include migration notes for breaking changes

  11. Communicate breaking changes:

  12. Update documentation
  13. Add prominent notes in release description

  14. Consider a major version bump

  15. Test installation:

  16. Test the install script after release
  17. Verify binaries work on target platforms

Troubleshooting

Release workflow fails

  • Check the Actions tab for error messages
  • Verify goreleaser.yaml is valid: goreleaser check
  • Ensure all required secrets are configured

Tag already exists

# Delete and recreate if needed
git tag -d v0.2.0
git push origin :refs/tags/v0.2.0
git tag v0.2.0
git push origin v0.2.0

Missing artifacts

  • Verify build configuration in goreleaser.yaml
  • Check build logs in GitHub Actions
  • Test locally with goreleaser release --snapshot --clean

Next steps