在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:adamralph/minver开源软件地址:https://github.com/adamralph/minver开源编程语言:C# 99.7%开源软件介绍:MinVerA minimalist .NET package for versioning .NET SDK-style projects using Git tags. Platform support: all platforms supported by .NET SDK-style projects. Also available as a command-line tool for use in any Git repository. PrerequisitesQuick start
Your project will be versioned according to the latest tag found in the commit history. To build with GitHub Actions, set the fetch depth appropriately. UsageWhen you want to release a version of your software, whether it's a pre-release, RTM, patch, or anything else, simply create a tag with a name which is a valid SemVer 2.x version and build your projects. MinVer will apply the version to the assemblies and packages. (If you like to prefix your tag names, see the FAQ.) NOTE: The MinVer package reference should normally include How it works
HeightIf the current commit does not have a version tag, another number is added to the pre-release identifiers. This is the number of commits since the latest commit with a version tag or, if no commits have a version tag, since the root commit. This is known as "height". For example, if the latest version tag found is This behaviour can be disabled. Version numbersMinVer sets the following custom properties:
Those properties are used to set the following .NET SDK properties, satisfying the official open-source library guidance for version numbers:
This behaviour can be customised. OptionsOptions may be specified as either MSBuild properties (for the MinVer package), command-line options (for the minver-cli package), or environment variables (for both the MinVer and minver-cli packages).
Note that the names of the MSBuild properties and environment variables are case-insensitive. FAQ(With TL;DR answers inline.)
Why not use GitVersion, Nerdbank.GitVersioning, or some other tool?Before starting MinVer, Adam Ralph evaluated both GitVersion and Nerdbank.GitVersioning, but neither of them worked in the way he wanted for his projects. The TL;DR is that MinVer is simpler. "How it works" pretty much captures everything. Comparison with GitVersionTo some degree, MinVer is a subset of what GitVersion is. It's much simpler and doesn't do nearly as much. Some of the differences:
Comparison with Nerdbank.GitVersioningMinVer is a different approach and, again, simpler. Some of the differences are already listed under the comparison with GitVersion above. Essentially, Nerdbank.GitVersioning encapsulates the injection of the version into the build process from a config file. That means versions are controlled by commits to that config file. MinVer works purely on tags. That means MinVer doesn't need some of the types of things that come with Nerdbank.GitVersioning such as the config file bootstrapper, and it means the version is controlled independently of the commits. For example, you can tag a commit as a release candidate, build it, and release it. After some time, if the release candidate has no bugs, you can tag the same commit as RTM, build it, and release it. Also, Nerdbank.GitVersioning uses the git height for the patch version, which is undesirable. Either every patch commit has to be released, or there will be gaps in the patch versions released. Can I bump the major or minor version?Yes! You probably want to do this because at a point in time, on a given branch, you are working on a specific Before you create the first version tag on your branch, interim builds will use the latest version tag found in the commit history, which may not match the Tag a commitTag a commit in your branch with a version matching your git tag 1.0.0-alpha.0 This is not a version you will release, since the first "alpha" version will be If you begin to release versions in the Set MinVerMinimumMajorMinorSpecify your range with <PropertyGroup>
<MinVerMinimumMajorMinor>1.0</MinVerMinimumMajorMinor>
</PropertyGroup> MinVer will now use a default version of If you begin to release versions in the Note that Also note that if the latest version tag found in the commit history has a higher Can I use my own pre-release versioning scheme?Yes! MinVer doesn't care what your pre-release versioning scheme is. The default pre-release identifiers are For example, all these versions work with MinVer:
Can I prefix my tag names?Yes! Specify the prefix with For example, if you prefix your tag names with "v", e.g. <PropertyGroup>
<MinVerTagPrefix>v</MinVerTagPrefix>
</PropertyGroup> Note that the prefix is case-insensitive—in this example, both Can I use my own branching strategy?Yes! MinVer doesn't care about branches. It's all about the tags! That means MinVer is compatible with Git Flow, GitHub Flow, Release Flow, and any other exotic flow. Can I include build metadata in the version?Yes! Specify build metadata with For example, in environment:
MINVERBUILDMETADATA: build.%APPVEYOR_BUILD_NUMBER% You can also specify build metadata in a version tag. If the tag is on the current commit, its build metadata will be used. If the tag is on an older commit, its build metadata will be ignored. Build metadata in Can I auto-increment the minor or major version after an RTM tag instead of the patch version?Yes! Specify which part of the version to auto-increment with Can I change the default pre-release phase from "alpha" to something else?Yes! Specify the default pre-release phase with <PropertyGroup>
<MinVerDefaultPreReleasePhase>preview</MinVerDefaultPreReleasePhase>
</PropertyGroup> This will result in a post-RTM version of Can I use the version calculated by MinVer for other purposes?Yes! You can use any of the properties set by MinVer, or override their values, in a target which runs after MinVer. For example, for pull requests, you may want to inject the pull request number and a variable which uniquely identifies the build into the version. E.g. using Appveyor: <Target Name="MyTarget" AfterTargets="MinVer" Condition="'$(APPVEYOR_PULL_REQUEST_NUMBER)' != ''" >
<PropertyGroup>
<PackageVersion>$(MinVerMajor).$(MinVerMinor).$(MinVerPatch)-pr.$(APPVEYOR_PULL_REQUEST_NUMBER).build-id.$(APPVEYOR_BUILD_ID).$(MinVerPreRelease)</PackageVersion>
<PackageVersion Condition="'$(MinVerBuildMetadata)' != ''">$(PackageVersion)+$(MinVerBuildMetadata)</PackageVersion>
<Version>$(PackageVersion)</Version>
</PropertyGroup>
</Target> Or for projects which do not create NuGet packages, you may want to populate all four parts of <Target Name="MyTarget" AfterTargets="MinVer">
<PropertyGroup>
<APPVEYOR_BUILD_NUMBER Condition="'$(APPVEYOR_BUILD_NUMBER)' == ''">0</APPVEYOR_BUILD_NUMBER>
<AssemblyVersion>$(MinVerMajor).$(MinVerMinor).$(APPVEYOR_BUILD_NUMBER).$(MinVerPatch)</AssemblyVersion>
</PropertyGroup>
</Target> Or for projects which do create NuGet packages, you may want to adjust the assembly file version to include the build number, as recommended in the official guidance. E.g. when using Appveyor: <Target Name="MyTarget" AfterTargets="MinVer">
<PropertyGroup>
<APPVEYOR_BUILD_NUMBER Condition="'$(APPVEYOR_BUILD_NUMBER)' == ''">0</APPVEYOR_BUILD_NUMBER>
<FileVersion>$(MinVerMajor).$(MinVerMinor).$(MinVerPatch).$(APPVEYOR_BUILD_NUMBER)</FileVersion>
</PropertyGroup>
</Target> Can I version multiple projects in a single repository independently?Yes! You can do this by using a specific tag prefix for each project. For example, if you have a "main" project and an "extension" project, you could specify Note that changes committed to a given project will affect the versions of all other projects because every commit affects height. To prevent this, you can ignore the height of the latest tag or root commit. Can I ignore the height of the latest tag or root commit?Yes! Set <PropertyGroup>
<MinVerIgnoreHeight>true</MinVerIgnoreHeight>
</PropertyGroup> This is often useful if you are versioning multiple projects in a single repository independently. Can I get log output to see how MinVer calculates the version?Yes!
These verbosity levels match those in MSBuild and therefore The equivalent levels for the minver-cli
These verbosity levels match those typically used in console applications. At the In a future version of MinVer, the verbosity level may be inherited from MSBuild, in which case Can I use MinVer to version software which is not built using a .NET SDK style project?Yes! MinVer is also available as a command-line tool. Run Sometimes you may want to version both .NET projects and other outputs, such as non-.NET projects, or a container image, in the same build. In those scenarios, you should use both the command-line tool and the regular MinVer package. Before building any .NET projects, your build script should run the command-line tool and set the If the components of the version are required outside the context of a .NET project, they can easily be extracted from the version which is returned by the command-line tool. The major, minor, and patch numbers can be separated from the pre-release identifiers by splitting the version by the first instance of Can I disable MinVer?Yes! Set <PropertyGroup>
<MinVerSkip Condition="'$(Configuration)' == 'Debug'">true</MinVerSkip>
</PropertyGroup> What if the history diverges, and more than one tag or root commit is found?MinVer will use the tag with the higher version, or the tag or root commit on the first path followed where the history diverges. The paths are followed in the same order that the parents of the commit are stored in git. The first parent is the commit on the branch that was the current branch when the merge was performed. The remaining parents are stored in the order that their branches were specified in the merge command. What if the history diverges, and then converges again, before the latest tag (or root commit) is found?MinVer will use the height on the first path followed where the history diverges. The paths are followed in the same order that the parents of the commit are stored in git. The first parent is the commit on the branch that was the current branch when the merge was performed. The remaining parents are stored in the order that their branches were specified in the merge command. Why is the default version sometimes used in GitHub Actions and Travis CI when a version tag exists in the history?By default, GitHub Actions and Travis CI use shallow clones. The GitHub Actions checkout action clones with a depth of only a single commit, and Travis CI clones with a depth of 50 commits. In GitHub Actions, if the latest version tag in the history is not on the current commit, it will not be found. In Travis CI, if the latest version tag in the history is at a height of more than 50 commits, it will not be found. To build in GitHub Actions or Travis CI, configure them to fetch a sufficient number of commits. For GitHub Actions, set the - uses: actions/checkout@v2
with:
fetch-depth: 0 For Travis CI, set the git:
depth: false Why is my version tag ignored?Things to check:
If you still can't figure it out, increase Tag by Ananth from the Noun Project. |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论