Published by marco on
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*.
quino
command-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:
[Major].[Minor].[Patch].[Build]
[Major].[Minor].[Patch]-[Label][Build]
See Microsoft’s NuGet Package Version Reference for more information.
0.9.0-alpha34
: A pre-release of 0.9.00.9.0-beta48
: A pre-release of 0.9.00.9.0.67
: An official release of 0.9.01.0.0-rc512
: A pre-release of 1.0.01.0.0.523
: An official release of 1.0.0The 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 versioning”>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 1.0.0.523
exists, then there will never be a 1.0.0.524
. 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 1.0.0.523
. NuGet will not offer to upgrade to 1.0.0.524
.
There are no restrictions on the labels for pre-releases. However, it’s recommended to use one of the following:
alpha
beta
rc
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 feature/[label]
where [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 mvb/[label]
.
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 1.0.1.0
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 releaseFor example,
origin/release/1
origin/production/release/new
origin/release/
release/1
production/release/new
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.
For example,
origin/feature/beta
yields beta
origin/feature/rc
yields rc
origin/mvb/rc
yields rc
The following algorithm ensures that the label can be part of a valid semantic version.
X
after a trailing digitX
if the label is empty (or becomes empty after having removed invalid characters)For example,
origin/feature/rc1
yields rc1X
origin/feature/linuxcompat
yields linuxcompat
origin/feature/12
yields X
Assume that,
Then,
origin/release/1
produces artifacts with version number 0.9.0.522
origin/feature/rc
produces artifacts with version number 0.9.0-rc522
The following are very concise guides for how to produce artifacts.
feature/rc
, master
)quino fix -v 1.0.2.0
release/1
)quino fix -v 1.0.2.0`
)