What does HackerNews think of semantic-release?

:package::rocket: Fully automated version management and package publishing

Language: JavaScript

https://news.ycombinator.com/item?id=36959007 | Aug 2023
Release Train will automatically create a new GitHub release every time you merge a pull request into main or whatever release branches you set up. It's inspired by semantic-release[1] but takes a different approach. Instead of using commit messages it uses PR labels to determine the type of release. This makes it easier to use. It's also a single binary so it doesn't require npm or any other package manager.

It comes in the forms of both cli and GitHub Action.

The downside of this approach is that it ties you to GitHub. It could be extended or forked to support any platform that has something like a pull request with labels. I'm comfortable adding that to the technical debt I will incur migrating away from GitHub.

I would love to get notes from the hn community on this.

[1] https://github.com/semantic-release/semantic-release

Idiot Proof Git | Nov 2022
Expand Context ↕
For a nice record of history - rather than squashing all of the smaller commits into a single commit for a given feature, and then rebasing (which makes it less easy to have small commits with specific explanations that add together to create a feature), something like semantic-release [1] could be used, which autogenerates release notes based on commit messages.

[1] https://github.com/semantic-release/semantic-release
How to Write a Great Git Commit Message | Apr 2022
I like the conventional commit style [0]. You may have seen these in open source repos or used them at work. They look like

feat: support new line chart

fix: update props for new line chart

chore: bump dependency version

What's also cool is there are tools (semantic release) that will then handle automatically the versioning and publishing of your module based on these commits using the commit type (feat, fix, chore etc) to determine the next appropriate version [1].

[0]https://www.conventionalcommits.org/en/v1.0.0/

[1]https://github.com/semantic-release/semantic-release

Semantic Git Commit Messages | Sep 2021
Especially great when combined with https://github.com/semantic-release/semantic-release

Also just ran across this, looks interesting: https://github.com/zeke/semantic-pull-requests

Conventional Commits | Aug 2020
Expand Context ↕
^ https://github.com/semantic-release/semantic-release
Git: A Guide to Proper Use | Aug 2019
Conventional Commit Standard [0] aims to solve this problem. Added to it is a good ecosystem of tools like Commitlint [1], Commitzen [2], Semantic Release [3] etc.

[0] https://www.conventionalcommits.org/en/v1.0.0-beta.2/

[1] https://github.com/conventional-changelog/commitlint

[2] https://github.com/commitizen/cz-cli

[3] https://github.com/semantic-release/semantic-release

Greenkeeper: Always up-to-date npm dependencies | Sep 2015
Expand Context ↕
Heya, you summed up the problem perfectly and we are not trying to be all clever solving this unsolvable riddle.

All Greenkeeper does is send you a Pull Request, which then runs your test. Only when you as the maintainer are satisfied this works, you get to merge the PR.

We have another project https://github.com/semantic-release/semantic-release that you can use to make sure your project leaves semver to computers and keeps humans out of the process, because they tend to screw this up.

With both Greenkeeper and semantic-release, we hope to get npm into shape that we, one day, can do more automated updates and it’s gonna be a long road, but we’ll have to start somewhere.

For now, Greenkeeper takes a lot of the chores out of the process you described to well in your comment.