Hi everyone

Since I introduced Sampo here, I’ve written a longer article that goes into the motivations behind the project, the design philosophy, and some ideas for what’s next. I hope you find this interesting!

Very timely, I’m recently doing one final pass out evaluating various such tools. Thanks for releasing yours!

Thanks for checking it out!

If you’re comparing options, there’s an « Alternatives » section in my article that outlines how Sampo compare to other tools: https://goulven-clech.dev/2025/introducing-sampo#alternatives.

I’m in active development, so if you find anything missing or have specific needs, please let me know and I’ll see what I can do

Hey, I finally got around to this. I wanted to tell you that after reviewing sampo I found it a bit heavy for my needs. I am mostly looking for manually bumping whichever part of the version I want and I want to be in charge of deciding that. Add also git tagging and GitHub release notes. That’s mostly what I need.

While I am open to have a tool auto-generate more things for me in the future, I still am not sure I would want it to decide for me whether a major, minor, or patch version must be bumped. I am also not 100% sold on conventional commits which many other tools use to make that call f.ex. Ash’s creator @zachdaniel’s GitHub - zachdaniel/git_ops: A tool for version and changelog management in Elixir via conventional commits. · GitHub tool, though his allows us to only opt in to version management inside mix.exs when we want to.

Thanks for your contribution, the tools looks amazing and I will always kind of shill for Rust tools because a multitude of them have been a net positive to my workflows. It’s just that the library that I am about to release is a much more manual and hands-on in nature when it comes to releases. I’ll reevaluate sampo in the near future because I’ll start another library soon after the first one gets released. And I might need it for some customer projects, too.

Hi @dimitarvp ,

Sorry for the slow reply, my weeks have been pretty packed lately and I’m only now catching up properly.

Thanks again for taking the time to check out Sampo. Just to clarify a couple of things :

Sampo never decides the bump level on its own: you explicitly declare the bump (patch, minor, or major), the packages affected, and the user-facing description of the change, either via the CLI or by editing the changeset file by hand. Sampo then just does the deterministic SemVer math from there. There’s no hidden logic trying to guess what the next version “should” be.

Sampo also doesn’t depend on Conventional Commits at all. One of the design goals was precisely to avoid mixing the technical history in git (written for and by contributors) with the API changelog (written for users, and sometimes reviewed/edited by product/docs owners). Changesets are the single source of truth, and the changelog and versions are generated from those.

It’s also meant to be modular. You can use it only to bump versions, generate changelogs, create git tags and GitHub releases, without letting it publish to registries. Similarly, you can stick to the CLI locally, and ignore both the GitHub App and the GitHub Action. The intent is that Sampo should be easy to opt in and out of, with as few assumptions, conventions, or lock-ins as possible. If there are still rough edges or sources of friction that made it feel “too heavy” in practice, I’m genuinely interested in hearing about them so I can keep smoothing things out

Thanks for the follow-up, much appreciated.

Sadly can’t remember now but I think it was mostly the volume of the blog post + the changesets thing.

But seeing as I had to spend a few hours on a bash script together with an LLM to just be able to release my own package with GIT tagging and bumping+syncing a version between mix.exs and Cargo.toml and nothing much else – and the shell script still ballooned to nearly 200 lines due to having to catch error and double-check errors – then re-reviewing sampo starts making more and more sense.

Not a remark towards you or the tool – but I find myself very puzzled at the current state of affairs. To be more concrete, these are the steps I need to release my package:

• Bump the version to what is desired (determined by one of the three: patch / minor / major)
• Set it inside mix.exs
• Set it inside Cargo.toml (my library has a Rust NIF)
• Make a GIT commit
• Make a GIT tag
• Push to the GIT remote
• Make a GitHub release
• Do mix hex.publish

My script is at nearly 200 lines and I still do the last 3 manually.

My main point of criticism, to your tool or any other, is that this is a mechanical logistical work that should have minimal involvement from the programmer.

This is my bucket list above. I use cargo-edit to directly set the version in the Cargo.toml file and mix_version to change the version in mix.exs – I don’t want to rely on UNIX text CLI tools for it. Hopefully that list is useful for you.

For the record, I dig the idea of the changesets a lot but I’ve dragged my feet on releasing my library for years – bad health, general being super busy, family emergencies and previous burnout were involved – so I just wanted to get it over with. I am very likely to revisit sampo soon-ish.

Oh, just for the record for you or anyone else, here’s the bash abomination that me and Gemini worked on for about an hour in order to cover most failure modes and use proper native tools and not just use brittle CLI text manipulation: xqlite/scripts/release.sh at 5fd91f15c748f18bf5a0a91ebe39df252ef9f5ed · dimitarvp/xqlite · GitHub

Monstrosity. Just to bump a version in two files and do a little GIT magic.

It’s almost 2026. All this stuff should have been figured out and written in stone 10 years ago. Shameful. But maybe when I retire I’ll have the time.

Thanks for sharing all this context, I really get those periods where everything stacks up, and you’re just trying to ship something…

Tbh the blog post is really there as a deep dive into Sampo, but as I mention in the first paragraphs, it’s absolutely not required reading to use the tool. The actual documentation is in the repo’s README. Sadly writing great docs isn’t exactly my superpower, but I try to keep it concise, practical, and complete enough

In practice, getting started with Sampo is very lightweight: you run sampo init once, then sampo add each time you want to add a changeset. The CLI guides you through selecting the bump level, the affected package(s), and the user-facing description, then you just commit the generated markdown file in the PR or commit where the change happens. The defaults should be fine for most projects, so you don’t need to touch the config file at all; but if you do, the config options are described here.

For the release and publishing side, the easiest path is usually the GitHub Action. If you want to try Sampo quickly, you can basically hand your AI agent the main README (or even just the repo link) and/or the Action README, and let it wire up. Once it’s in place, Sampo will automatically open a release PR whenever there are unconsumed changesets, and merging that PR will take care of the changelog, GitHub releases, git tags, and publishing to Hex (with your Hex token set as an environment variable).

If you do end up revisiting Sampo and run into any friction, I’m genuinely interested in hearing about it. Your “bucket list” of steps is exactly the kind of workflow I want to make boring and reliable!

I did not notice this. Thanks, this actually makes me want to try it again sooner.

You can actually see the GitHub Action in action (lol) on Bruits’ public repos, both Maudit and Sampo itself have currently an automatic release PR open, and there are quite a few closed ones in the history as well.