4. A Definition…
“…simple set of rules and requirements that dictate how version
numbers are assigned and incremented. These rules are based on
but not necessarily limited to pre-existing widespread common
practices in use in both closed and open-source software.”
Reference
http://semver.org
5. The Rules
Given a version number MAJOR.MINOR.PATCH, increment the:
• MAJOR version when you make incompatible API changes
• MINOR version when you add functionality in a backwards-
compatible manner
• PATCH version when you make backwards-compatible bug fixes
Additional labels for pre-release and build metadata are available as
extensions to the MAJOR.MINOR.PATCH format.
6. Example Semantic Version Numbers
• 0.1.0
• 1.0.0
• 0.3.13
• 0.2.0-unstable3
• 0.2.0-unstable.3+Branch.develop.Sha.e6eb071cd30974b80d7e237b85e7729a1d791e1e
8. A Definition…
“GitVersion is a tool to help you achieve Semantic Versioning on
your project.”
Reference
http://gitversion.readthedocs.org/en/latest/
https://github.com/GitTools/GitVersion
16. Questions?
Feel free to get in touch
Email: gep13@gep13.co.uk
Twitter: @gep13
Web: http://www.gep13.co.uk
17. Resources
• GitVersion Documentation
o http://gitversion.readthedocs.org/en/latest/
• .Net Rocks Episode with Jake Ginnivan
o https://www.dotnetrocks.com/default.aspx?showNum=1178
• Git Branching Strategies
o https://www.atlassian.com/git/tutorials/comparing-workflows
• GitFlow
o http://nvie.com/posts/a-successful-git-branching-model/
Notes de l'éditeur
The Semantic Versioning specification is authored by Tom Preston-Werner, inventor of Gravatars and co-founder of GitHub.
Tries to solve two problems, Version Lock and Version promiscuity.
SemVer introduces conventions about breaking changes into our version numbers so we can safely upgrade dependencies without fear of unexpected breaking changes while still allowing us to upgrade downstream libraries to get new features and bug fixes.
{major} = Only incremented if the release has breaking changes (includes bug fixes which have breaking behavioural changes{minor} = Incremented if the release has new non-breaking features{patch} = Incremented if the release only contains non-breaking bug fixes{tag} = Optional -{tag} denotes a pre-release of the version preceeding{buildmetadata} = Options +{buildmetadata} contains additional information about the version, but DOES NOT AFFECT the semantic version preceding it.
- It actually started out as two tools, one by Particular and another by Jake Ginnivan
- They decided to combine their efforts under the ParticularLabs Open Source Repository
- Ownership of GitVersion has since passed to the GitTools organisation which is creating a number of OSS tools, centred around Git
GitReleaseNotes, GitReleaseManager, GitLink, etc
- Uses LibGit2, same library as used by GitHub For Desktop, and the Visual Studio Git Integration
Version.txt - Results in multiple commits to repository that aren’t required
- Difficult to between branches
CI Build - Tied into one CI System
AssemblyInfo - Very manual process
- Someone has to remember to do it
Unknown - Less said about this, the better
I have never used the Ruby Gem, but as I understand it, it is just a wrapper around the exe.
There is also a GitVersion DLL which can be consumed in your own applications, but it should be noted that there is not currently a public defined API, so care should be taken.
Not all Build Servers clone all branches, necessary for asserting the version number, which means GitVersion can fail.
This will make GitVersion Variables:
- immediately available to other build steps
- set the build version number
- rationalise the branches, and ensure all required branches are cloned, in order to assert version number
- automatically detect that it is running on a build server