Analysis updated 2026-07-03 · repo last pushed 2025-03-31
Automatically generate a categorized changelog from commit history when cutting a new release.
Create and manage GitHub milestones that group all issues closed since the last version tag.
Publish a GitHub release with a pre-filled description and auto-close the milestone on final release.
| syncthing/github-release-tool | gnana997/periscope | syncthing/roadmap-votes | |
|---|---|---|---|
| Stars | 6 | 6 | 5 |
| Language | Go | Go | Go |
| Last pushed | 2025-03-31 | — | 2026-05-26 |
| Maintenance | Stale | — | Maintained |
| Setup difficulty | moderate | moderate | moderate |
| Complexity | 2/5 | 4/5 | 2/5 |
| Audience | developer | ops devops | developer |
Figures from each repo's GitHub metadata at analysis time.
Requires a GitHub API token and strict adherence to commit message and issue labeling conventions (e.g., 'fixes #1234', bug/enhancement labels, semantic versioning).
GitHub Release Tool is a command-line utility that automates the tedious parts of shipping a new software version. Instead of manually tracking down which bugs were fixed and which features were added, it reads your commit history, collects the relevant issues, groups them into a release milestone on GitHub, and generates a formatted changelog you can publish. The tool works by looking for specific patterns in your commit messages. When you write something like "fixes #1234" in a commit, it knows that issue 1234 was resolved by that change. At release time, you point it at your last version tag, and it scans everything since then to find all the closed issues. It then creates a GitHub milestone with those issues, so anyone browsing your repository can see exactly what's coming in the next release. From there, you can generate a changelog that sorts issues into bugs, enhancements, and other categories. When you're ready to publish, the tool creates the actual GitHub release and fills in the description with that changelog. If you're putting out a release candidate with a different version number, it marks it as a pre-release and keeps the milestone open. When you ship the final version, it closes the milestone automatically. This is built for teams that already follow a specific workflow: they use "bug" and "enhancement" labels on issues, reference issue numbers in commits, and use semantic versioning. It's a tool created by the Syncthing project for their own needs, and it reflects that team's established habits rather than trying to be a universal solution for every project. A notable tradeoff is that it only works if you commit to its conventions up front. There's no flexibility in how issues are referenced or labeled, you either match its expectations or it won't find anything. For a small team with consistent practices, that's a reasonable deal: less configuration, more automation.
A command-line tool that reads your commit history, finds closed issues, groups them into GitHub milestones, and generates formatted changelogs for publishing GitHub releases automatically.
Mainly Go. The stack also includes Go, GitHub API, CLI.
Stale — no commits in 1-2 years (last push 2025-03-31).
No license information is provided in this explanation, so the licensing terms are unknown.
Setup difficulty is rated moderate, with roughly 30min to a first successful run.
Mainly developer.
This repo across BitVibe Labs
Verify against the repo before relying on details.