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.
This must be some strange new definition of "branchless" with which I'm not previously familiar; the generated code is full of branches, conditional or otherwise. I don't think invoking some other tool to put branches into your code qualifies you as branchless.
Have you compared your parser to simdjson-go? I haven't looked specifically at the go rewrite, but I hear it's decent.
I was very excited to do branch free coding to parse JSON, but really only handled the 'lexing' portion of the task in branch free fashion. Certainly more of the task could be done branch free, especially if you are working on SIMD or GPGPU.
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 sure I believe your benchmarks, honestly. They are way slower than the C++ version. But I don't really have a horse in the race as simdjson-go is its own thing. Still, I'm mildly surprised that a byte-by-byte parser is the same speed as a SIMD approach, and usually when someone tells me this, the answer is usually that they buggered up the benchmarking. I would suggest comparing your numbers to the simdjson paper or whatever brag numbers simdjson-go has as a reality check; one of us is clearly wrong.
The use of parallelism in simdjson is the use of SIMD instructions, not multiple cores. So the answer is "no" to the second question.
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.
This is exactly correct. I haven't finished the pull request feature yet, what you're seeing on the repo is just issues. I will be taking requests for any desired features
“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.
