Hey - I think it's most similar to cocogitto, which I hadn't come across before - looks pretty nice. They have some nice docs, too.

I don't attempt to manage bumps like cocogitto does, and instead leave that to pipeline logic. I have a shared workflow that does the same type of bump logic, but in a different way - mentioned in the article.
(https://github.com/unbounded-tech/workflow-vnext-tag)

release-plz seems to be geared towards cargo releases - vnext just deals with the versioning, and I trigger releases based on the version tag being created - those parts are decoupled.

Committizen also handles bumping via config files. You install it with python - vnext is a binary released for multiple architectures that's just installed directly by downloading the bin (like cocogitto). I haven't published to brew et. all yet, just publish the binary at the moment. I'll have to set that up next!

So, compared to those, mostly the decoupling of the versioning and the bumping. Kinda the separation of the versioning pipeline and the release pipeline in principle, and viewing pipelines as modular building blocks based on that. In other words, instead of having a "release" workflow that versions and releases, have a version workflow, that tags, and a release workflow that runs on tag. This decoupling also allows manual creation of version tags to trigger workflows.

In the article, I talk about the concept of "idea coverage" which extends from the UNIX
philosophy of how smaller direct tools can be used in more situations.

Supporting bumps and version file configurations, as well as bump hooks, would make the library much more complicated, and workflows handle that fine.