GitVersion VS semantic-release

Gitversion: It reads your commit history and generates a semver version out of it. Say you are compiling main branch and have a tag 1.0. Then, you squash 3 PRs. When you build this version, the new version number will be 1.0.3. You can configure it to be smarter about increasing major, minor, patch fields. I typically use prefix on the commit messages so that it generates versions correctly. See more at https://gitversion.net/docs/

GitVersion is not available by default and needs to be installed beforehand if we want to use the features it offers. The action is available here.

Check this out https://gitversion.net/docs/

At work we use https://gitversion.net/docs/ in our devops pipelines. Similaf to git-semver it generates a version based on what's published previously.

Under Linux I use gitflow and gitversion. The former helps me with branch and tags management, the latter keep tracks of the semantic version in a semi-automatic fashion (given a branch/commit/tag it generate a semver automatically based on the repo log). Gitflow should be supported by GUI tools too, but I'm more a CLI guy.

I know that GitVersion exists, which I think can automatically calculate the version number for me. But it's not entirely clear to me that it will do this. Also it doesn't seem to have a nbgv set-version equivalent that will just create a tag based on the calculated version number.

Kind of like you mention though, I tend to still create a build script using gitversion then just have the GitHub Action kick off the script. I find value in being able to create artifacts on a developer machine so having a simple script to run makes that as painless as possible and when I last looked a year or so ago there wasn't a good way of running GitHub Actions on your development machine.

Self promotion: I made Verlite for this purpose, tho something like GitVersion might be more suitable for your workflow.

We use gitversion to generate semver based on commit height. https://github.com/GitTools/GitVersion

GitHub - GitTools/GitVersion: From git log to SemVer in no time

Conventional commits specification contains a set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of, for example, semantic release. You can manually follow this convention in your project or use a tool to assist you, such as Commitizen.

When working with JavaScript projects, managing version numbers and commit messages is important for the maintainability of the project. Since 2020 I have been the main developer of Atomic Calendar Revive a highly customisable Home Assistant calendar card, I found maintaining versions and releases to be cumbersome until recently. In this article, I will introduce the commitizen and semantic-release packages for creation or appropriate commit messages and semantic versioning. I will also provide examples of how I am currently using these packages to streamline my release workflow and project maintenance.

To further streamline deployments, I introduced semantic-release. This tool automates commit tagging and tracks changes since the previous version. As a result, deployments now occur only when new tags are present, saving us valuable minutes.

If your projects ar made in javascript and related tools, I'd suggest you to check: semantic-release

In an ideal world, that our team hasn't gotten to just yet, the whole manual release process gets replaced with semantic-release anyway and there's no need for the release hook. Unfortunately some of us can be inconsistent or incorrect with our commit messages, so we're not quite ready for it yet.

semantic-release - My current tool of choice. semantic-release depends on commit messages that follow Angular's commit message conventions for versioning. Unfortunately, it doesn't play nice with monorepos (for more details, here's a little extra credit reading The chronicles of semantic-release and monorepos).