Any software product should have a version number. This article will answer the following questions about how Encodo works with them.
In decreasing order of expected expertise,
The intended audience of this document is developers.
quinocommand-line tool is installed on all machines. This tool can read and write version numbers for any .NET solution, regardless of which of the many version-numbering methods a given solution actually uses.
Encodo uses semantic versions. This scheme has a strict ordering that allows you to determine which version is "newer". It indicates pre-releases (e.g. alphas, betas, rcs) with a "minus", as shown below.
Version numbers come in two flavors:
See Microsoft's NuGet Package Version Reference for more information.
0.9.0-alpha34: A pre-release of 0.9.0
0.9.0-beta48: A pre-release of 0.9.0
0.9.0.67: An official release of 0.9.0
1.0.0-rc512: A pre-release of 1.0.0
184.108.40.2063: An official release of 1.0.0
The numbers are strictly ordered. The first three parts indicate the "main" version. The final part counts strictly upward.
The following list describes each of the parts and explains what to expect when it changes.
This part is also known as "Maintenance" (see Software versioning on Wikipedia).
There will only ever be one artifact of an official release corresponding to a given "main" version number.
That is, if
220.127.116.113 exists, then there will never be a
18.104.22.1684. This is due the fact that the build number (e.g. 524) is purely for auditing.
For example, suppose your software uses a NuGet package with version
22.214.171.1243. NuGet will not offer to upgrade to
There are no restrictions on the labels for pre-releases. However, it's recommended to use one of the following:
Be aware that if you choose a different label, then it is ordered alphabetically relative to the other pre-releases.
For example, if you were to use the label
pre-release to produce the version
0.9.0-prealpha21, then that version is considered to be higher than
0.0.0-alpha34. A tool like NuGet will not see the latter version as an upgrade.
The name of a release branch should be the major version of that release. E.g.
release/1 for version 1.x.x.x.
The name of a pre-release branch should be of the form
[label] is one of the labels recommended above. It's also OK to use a personal branch to create a pre-release build, as in
A developer uses the
quino tool to set the version.
For example, to set the version to 1.0.1, execute the following:
quino fix -v 126.96.36.199
The tool will have updated the version number in all relevant files.
The build server calculates a release's version number as follows,
The name of the Git branch determines which kind of release to produce.
**/release/*, then it's an official release
The name of the branch doesn't influence the version number since an official release doesn't have a label.
The label is taken from the last part of the branch name.
The following algorithm ensures that the label can be part of a valid semantic version.
Xafter a trailing digit
Xif the label is empty (or becomes empty after having removed invalid characters)
origin/release/1produces artifacts with version number
origin/feature/rcproduces artifacts with version number
The following are very concise guides for how to produce artifacts.
quino fix -v 188.8.131.52
quino fix -v 184.108.40.206
Sign up for our Newsletter