Custom tag format

Full config for a repo that tags releases as release/v1.2.0 instead of the default v1.2.0. Swap the pattern for any shape you like — see Tag formats for the {prefix} and {version} placeholder reference.

.releasejet.yml

provider:
  type: github
source: issues
tagFormat: "release/v{version}"
categories:
  feature: "New Features"
  bug: "Bug Fixes"
  improvement: "Improvements"
  breaking-change: "Breaking Changes"
uncategorized: lenient

tagFormat must contain {version}. {prefix} is optional and only used for multi-client repos.

GitHub Actions

.github/workflows/release-notes.yml:

name: Release Notes
on:
  push:
    tags:
      - 'release/v*'
jobs:
  release-notes:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm i -g @makispps/releasejet
      - run: releasejet generate --tag "${{ github.ref_name }}" --publish
        env:
          RELEASEJET_TOKEN: ${{ secrets.RELEASEJET_TOKEN }}

Match the on.push.tags glob to your pattern — release/v* for the example above.

Workflow

1. Label issues as they close (feature, bug, ...).
2. Tag the release: git tag release/v1.2.0 && git push origin release/v1.2.0.
3. The workflow runs, matching release/v*, and publishes the release.

Migrating to a new format

If you change tagFormat on a repo that already has tags in the old format, the next generate aborts with an actionable error — ReleaseJet detects the orphan tag and suggests --since. See Migrating to a new tag format for the full flow.

Tips

• The glob in your CI trigger and tagFormat must agree. A pattern like {version} with trigger v* won't fire for a tag like 1.2.0 because v* expects the v prefix.
• Prefer patterns that include a non-version segment (release/v{version}, {prefix}@{version}) — they avoid confusion with raw semver tags sometimes created by tooling.