Versionize

stop using weird build scripts to increment your nuget's version, use versionize!

Automatic versioning and CHANGELOG generation, using conventional commit messages.

how it works:

1. when you land commits on your master branch, select the Squash and Merge option (not required).
2. add a title and body that follows the Conventional Commits Specification.
3. when you're ready to release a nuget package:
   1. git checkout master; git pull origin master
   2. run versionize
   3. git push --follow-tags origin master
   4. dotnet pack
   5. dotnet nuget push

versionize does the following:

1. bumps the version in your .csproj file (based on your commit history)
2. uses conventional-changelog to update CHANGELOG.md
3. commits .csproj file and CHANGELOG.md
4. tags a new release

Installation

dotnet tool install --global Versionize

Usage

Usage: versionize [options]

Options:
  -?|-h|--help                         Show help information
  -v|--version                         Show version information
  -w|--workingDir <WORKING_DIRECTORY>  Directory containing projects to version
  -d|--dry-run                         Skip changing versions in projects, changelog generation and git commit
  --skip-dirty                         Skip git dirty check
  -r|--release-as <VERSION>            Specify the release version manually
  --silent                             Suppress output to console
  -i|--ignore-insignificant-commits    Dont do anything when only insignificant commits (anything other then fix, feat, or BREAKING) are found

Supported commit types

Every commit should be in the form <type>[optional scope]: <description> for example fix(parser): remove colon from type and scope

• fix - will trigger a patch version increment in the next release
• feat - will trigger a minor version increment in the next release
• all other types - you can use any commit type but that commit type will not trigger a version increment in the next release

Breaking changes must contain a line prefixed with BREAKING CHANGE: to allow versionize recognizing a breaking change. Breaking changes can use any commit type.

Example

git commit -m "chore: update dependencies" -m "BREAKING CHANGE: this will likely break the interface"

The happy versioning walkthrough

Preparation

Create a new project with the dotnet cli

mkdir SomeProject
dotnet new classlib

Ensure that a <Version> element is contained in file SomeProject.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <Version>1.0.0</Version>
  </PropertyGroup>
</Project>

Using versionize

Now let's start committing and releasing

git init
...make some changes to "Class1.cs"
git add *
git commit -a -m "chore: initial commit"

versionize

Will add a CHANGELOG.md, add git tags and commit everything. Note that the version in SomeProject.csproj will not change since this is your first release with versionize.

...make some changes to "Class1.cs"
git commit -a -m "fix: something went wrong we need a bugfix release"

versionize

Will update CHANGELOG.md, add git tags and commit everything. Note that the version in SomeProject.csproj is now 1.0.1.

...make some changes to "Class1.cs"
git commit -a -m "feat: something really awesome coming in the next release"

versionize

Will update CHANGELOG.md, add git tags and commit everything. Note that the version in SomeProject.csproj is now 1.1.0.

...make some changes to "Class1.cs"
git commit -a -m "feat: a really cool new feature" -m "BREAKING CHANGE: the API will break. sorry"

versionize

Will update CHANGELOG.md, add git tags and commit everything. Note that the version in SomeProject.csproj is now 2.0.0 since versionize detected a breaking change since the commit note BREAKING CHANGE was used above.

Roadmap

• Pre Releases to allow creating beta.1, beta.2 versions
• --silent command line switch to suppress commandline output
• --should-version command line switch to test if a new version should be created based on commits and return a non zero exit code if no new version should be released