Switching release tools shouldn't mean rewriting your config by hand. ferrflow migrate reads an existing semantic-release setup and writes the equivalent ferrflow.json for you.

ferrflow migrate                        # auto-detects .releaserc
ferrflow migrate --from semantic-release

It maps what has a FerrFlow equivalent:

  • tagFormat: "v${version}"tagTemplate: "v{{version}}"
  • branches → FerrFlow channels — main/master become the stable line, a prerelease branch becomes a channel
  • @semantic-release/changelog → the package's changelog path
  • @semantic-release/exec → hooks (prepareCmdpreBump, publishCmdpostPublish, and the rest)
  • @semantic-release/github / gitlabforge

The point is what it does with the rest. Anything without a FerrFlow equivalent is surfaced, never guessed: @semantic-release/npm, custom commit-analyzer release rules, and repositoryUrl are each reported with a note on what to do, not silently dropped. The command prints a summary of what mapped, what it ignored, and what needs a manual look — and it won't overwrite a config you already have.

Migrated semantic-release config from .releaserc → ferrflow.json

Mapped:
  • tagFormat → tagTemplate (v${version})
  • branch main → stable
  • branch beta → prerelease `beta`@semantic-release/github → forge

Review manually:
  ! @semantic-release/npm → not mapped. Configure `publishers` by hand if you publish to npm.

JSON .releaserc is supported today; a YAML .releaserc or a JavaScript release.config.js is reported as unsupported rather than mis-read. After migrating, review the generated config, then run ferrflow validate and ferrflow check.