Skip to content

RELEASE.md

Latest commit

 

History

History
81 lines (56 loc) · 2.76 KB

RELEASE.md

File metadata and controls

81 lines (56 loc) · 2.76 KB
Raw

Release Process

This document describes the release process for git-ssh-signing-action.

Prerequisites

Before creating a release, ensure the following repository secrets are configured:

  • SSH_SIGNING_KEY - SSH private key for signing git tags
  • GIT_USER_NAME - Name for git commits (e.g., "Your Name")
  • GIT_USER_EMAIL - Email for git commits (e.g., "your-email@example.com")

Release Steps

  1. Prepare the release

    1. Update CHANGELOG.md. Based on the changes since the last release, decide if we need to increment the patch, minor, or major semantic version number.

    2. Ensure all tests pass and dist/ is up-to-date:

      npm run all

    3. Commit and push changes

  2. Create a GitHub Release

  3. Automated tag updates

    When you publish the release, the .github/workflows/release.yml workflow automatically:

    • Creates/updates floating major version tag (e.g., v1 for v1.2.3)
    • Creates/updates floating minor version tag (e.g., v1.2 for v1.2.3)
    • Signs all tags using the configured SSH key yay us

Version Strategy

There is no version to bump. This action is consumed as a GitHub Action via git tags, never published to npm, so package.json deliberately carries no version field (and is marked private). The tag you create in step 2 is the sole source of truth — don't reintroduce a version field to keep in sync by hand, as it will silently drift.

This action follows semantic versioning and maintains floating tags:

  • v1.2.3 - Specific version (immutable)
  • v1.2 - Latest patch version in 1.2.x series (moves with patch releases)
  • v1 - Latest version in 1.x.x series (moves with minor/patch releases)

Users can reference the action using any of these tags:

# Specific version (recommended for production)
- uses: photostructure/git-ssh-signing-action@v1.2.3

# Auto-update patch versions
- uses: photostructure/git-ssh-signing-action@v1.2

# Auto-update minor versions
- uses: photostructure/git-ssh-signing-action@v1

Versioning Guidelines

  • Major version (0.x.x → 1.0.0): Breaking changes
  • Minor version (0.1.x → 1.1.0): New features, backwards compatible
  • Patch version (1.1.0 → 0.2.1): Bug fixes, backwards compatible

Post-Release

After releasing:

  1. Verify the release workflow completed successfully
  2. Check that floating tags were updated: git fetch --tags && git tag -l
  3. Test the new version in a workflow