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:
- when you land commits on your
master
branch, select the Squash and Merge option (not required). - add a title and body that follows the Conventional Commits Specification.
- when you're ready to release a nuget package:
git checkout master; git pull origin master
- run
versionize
git push --follow-tags origin master
dotnet pack
dotnet nuget push
versionize
does the following:
- bumps the version in your
.csproj
file (based on your commit history) - uses conventional-changelog to update CHANGELOG.md
- commits
.csproj
file and CHANGELOG.md - tags a new release
dotnet tool install --global Versionize
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
--skip-commit Skip commit and git tag after updating changelog and incrementing the version
-i|--ignore-insignificant-commits Do not bump the version if no significant commits (fix, feat or BREAKING) are found
--changelog-all Include all commits in the changelog not just fix, feat and breaking changes
--commit-suffix Suffix to be added to the end of the release commit message (e.g. [skip ci])
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"
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>
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.
You can configure versionize
either by creating a .versionize
JSON file the working directory.
Any of the command line parameters accepted by versionized
can be provided via configuration file leaving out any -
. For example skip-dirty
can be provided as skipDirty
in the configuration file.
To get prettier test outputs run dotnet test
with prettier test logger
dotnet test --logger prettier
- Pre Releases to allow creating beta.1, beta.2 versions
- Support .versionrc like "standard-version" does
- Support mono repo joint and disjoint version strategies
-
--silent command line switch to suppress commandline output -
-i
,--ignore-insignificant-commits
command line switch to not create a new version if only insignificant (chore, ...) commits were done - GitHub URLs in changelog