Same question as LFSX#93, different answer — because the venues are different and half of them are already covered here.
Already done, and worth not redoing: the GitHub Marketplace listing exists (FerrFlow Release, published by FerrLabs, currently v7.0.3), the repository has ten relevant topics, the homepage points at ferrflow.com, and the CLI is on crates.io and npm. That is more groundwork than LFSX had.
What is missing is the one list that plays the role the git-lfs wiki plays for a LFS server.
The specification's own tooling list
conventionalcommits.org maintains Tooling for Conventional Commits and Projects Using Conventional Commits on its About page, and FerrFlow is on neither. Entries are one bullet, name-linked, one sentence:
- [commitlint](https://github.com/conventional-changelog/commitlint): A linter to check that your commit messages meet the Conventional Commits format.
It is a pull request to conventional-commits/conventionalcommits.org against content/about/index.md. That page is where someone who has just adopted the convention goes looking for what to run next, which is exactly the moment FerrFlow is relevant.
The sentence
The list already has commitizen, commitlint, semantic-release, cocogitto, git-cliff and a dozen changelog generators. "Reads conventional commits and cuts a release" describes several of them.
What does not: one binary that bumps 16 version-file formats across monorepos and classic repos alike — Cargo.toml, package.json, pyproject.toml, Chart.yaml, mix.exs, pubspec.yaml, gemspecs — with no runtime to install and no plugin to configure per ecosystem. Every close competitor is either single-ecosystem or a Node.js plugin host.
That is the sentence to write once and reuse.
Elsewhere, in rough order of value
Unlike LFSX, nothing here is gated on age: the first release was 30 March 2026, so the four-month rule that blocks LFSX until December is already satisfied.
What this does not need
A domain — ferrflow.com exists and is the product site. The work is entirely in being cited from where people already are, not in building another place for them to arrive at.
Same question as LFSX#93, different answer — because the venues are different and half of them are already covered here.
Already done, and worth not redoing: the GitHub Marketplace listing exists (FerrFlow Release, published by FerrLabs, currently v7.0.3), the repository has ten relevant topics, the homepage points at ferrflow.com, and the CLI is on crates.io and npm. That is more groundwork than LFSX had.
What is missing is the one list that plays the role the git-lfs wiki plays for a LFS server.
The specification's own tooling list
conventionalcommits.org maintains Tooling for Conventional Commits and Projects Using Conventional Commits on its About page, and FerrFlow is on neither. Entries are one bullet, name-linked, one sentence:
It is a pull request to conventional-commits/conventionalcommits.org against
content/about/index.md. That page is where someone who has just adopted the convention goes looking for what to run next, which is exactly the moment FerrFlow is relevant.The sentence
The list already has commitizen, commitlint, semantic-release, cocogitto, git-cliff and a dozen changelog generators. "Reads conventional commits and cuts a release" describes several of them.
What does not: one binary that bumps 16 version-file formats across monorepos and classic repos alike —
Cargo.toml,package.json,pyproject.toml,Chart.yaml,mix.exs,pubspec.yaml, gemspecs — with no runtime to install and no plugin to configure per ecosystem. Every close competitor is either single-ecosystem or a Node.js plugin host.That is the sentence to write once and reuse.
Elsewhere, in rough order of value
Unlike LFSX, nothing here is gated on age: the first release was 30 March 2026, so the four-month rule that blocks LFSX until December is already satisfied.
What this does not need
A domain — ferrflow.com exists and is the product site. The work is entirely in being cited from where people already are, not in building another place for them to arrive at.