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.
I apparently had a fundamental misunderstanding of the meaning of branchless. That's embarrassing.
As for simdjson-go, I did benchmark it. rjson outperformed simdjson-go in most benchmarks, but simdjson-go was about 3% faster reading citm_catalog.json.
I see on your bio that you are one of the simdjson authors. I hope you will indulge a question about it. I am generally more interested parsing a large volume of json documents efficiently than I am in doing it quickly. Since simdjson uses parallel instructions, would that mean that the speedup comes at the expense of being able to process more documents in parallel on the same hardware?
I’m not involved in this project, but I would guess that it’s because it validates both issues and PRs, but only PRs have statuses on GitHub, More precisely, only commits have statuses, and issues aren’t associated with commits.
“avatar_url” is the only part of that endpoint in preview, so that warning only applies to that field. I can see how the notification isn’t clear on that point, and I will bring that up.
This brings back a memory of a conversation with my grandfather. We were in Midland, and I said something about heading over to Odessa. He made a disparaging remark about my intelligence and said we would have to head out to Odessa from there.
Taste is dependent on the audience. An audience of kernel maintainers would probably share Linus' taste here, while an audience of enterprise developers would find the original code more palatable.