Semantic Versioning
Summary #
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 backward compatible manner - PATCH
- version when you make
backward compatible bug fixes
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
git tag and release #
release > tag
A tag is a git concept whereas a Release is Github higher level concept.
Releases are first-class objects with changelogs and binary assets that present a full project history beyond Git artifacts.
official release of “release” from github
A Release is created from an existing tag and exposes release notes and links to download the software or source code from Github.
stackoverflow, ref
tags appear like this the code and can be downloaded from each tag
release is created from tag in Github
v0.0.1 vs 0.0.1 or to use or not to use “v” #
No, “v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. Abbreviating “version” as “v” is often seen with version control. Example: git tag v1.2.3 -m “Release version 1.2.3”, in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.
stackoverflow, ref even with v the downloadable source code is generated, stackoverflow it is quite possible to use the versioning without “v” and loose nothing from semantic versioning, “v” is a convention.
Conclusion #
- From minimalist view point it is better to drop “v”.
- however one advantage of “v” can be in filtering (TODO: confirm this)
- decided to go with minimal approach: without “v”