I'm Makis. For years I've maintained codebases we ship to multiple customers on independent version tracks, and writing release notes by hand has been a pain.
I built ReleaseJet to automate it. There are existing tools for this (semantic-release, release-please, changesets) but none of them tackled our two problems:
1. We never adopted Conventional Commits. Our team labels issues and PRs, but we don't bother policing commit messages. All the existing tools assume the opposite of what we do.
2. We have one repo, many customers. We ship to many customers using independent tags (e.g., client1-v1.4.11, client2-v2.9.2). All other tools assume you have a single linear version history.
ReleaseJet reads your Git tags, pulls the closed issues (or merged PRs) between the current tag and the previous one on the same client track, groups them by a label → category mapping from a YAML file, and publishes formatted release notes to GitHub Releases or GitLab.
- GitHub + GitLab, issues or PRs
- Multi-client tag tracks out of the box
- 5-line GitHub Action on the Marketplace
- Free forever for public OSS repos
Hello HN,
I'm Makis. For years I've maintained codebases we ship to multiple customers on independent version tracks, and writing release notes by hand has been a pain.
I built ReleaseJet to automate it. There are existing tools for this (semantic-release, release-please, changesets) but none of them tackled our two problems:
ReleaseJet reads your Git tags, pulls the closed issues (or merged PRs) between the current tag and the previous one on the same client track, groups them by a label → category mapping from a YAML file, and publishes formatted release notes to GitHub Releases or GitLab. Live demo with three customer tracks and real published release pages: https://github.com/makisp/releasejet-demo-multi-customer/rel...It's free and open source on GitHub: https://github.com/makisp/releasejet (MIT)
I genuinely want to hear what's missing, what's broken, or how you've solved this differently.