Added VERSIONING.md
Versioning of releases will from now on differentiate again between potentially-breaking and non-breaking changes. Though, consider the currently existing API portions as still unstable: I will continue to preference API-breakage over 'workarounds'/fallbacks for now. Trailing zeros in version numbers might be omitted.master
parent
c9ef74214a
commit
7f2691b5cc
|
@ -0,0 +1,17 @@
|
|||
# Versioning scheme
|
||||
|
||||
The versioning scheme used by this software is similar to Semantic Versioning (https://semver.org/), with the following differences:
|
||||
* Additionally to ```Major``` for **backwards incompatible changes** (regarding API and behavior), we have an ```Epoch``` component at the beginning, which can be used to denote **especially significant** backwards incompatible changes (ex. a complete rewrite of the software, or to emphasize the effort or impact of an update). The ```Epoch``` component might not get incremented very often, or may for some software even stay the same during its complete lifetime.
|
||||
* We don't differentiate between the ```Minor``` and the ``` Patch``` components: We use a single ```Minor``` component for all types of **backwards compatible changes** (ex. feature additions, deprecations, bug fixes, corrected documentation).
|
||||
|
||||
Just like in Semantic Versioning, we can:
|
||||
* Denote **Pre-Releases** (ex. 1.0.0-alpha, 1.0.0-beta.3). During pre-releases anything may change at any time: The public API should not be considered stable.
|
||||
* Append additional build metadata (ex. build numbers, build dates, commit hashes).
|
||||
|
||||
**The overall version format looks like this:** ```Epoch.Major.Minor[-pre.id][+metadata]```
|
||||
|
||||
Additional notes on our versioning scheme:
|
||||
* The formatting and precedence rules are the same as defined by Semantic Versioning.
|
||||
* We may omit trailing components consisting of zeros (1.9.0 = 1.9, 1.9.0-alpha.0 = 1.9-alpha.0 = 1.9-alpha).
|
||||
* Alternatively to pre-release tags, an ```Epoch``` of 0 may be used to denote the initial development phase of the project. During this phase the constraints for the ```Major``` and ```Minor``` components are loosened and their meaning might be defined differently. Anything may change at any time: The public API should not be considered stable.
|
||||
* Versions are usually only assigned for (pre-)releases. Each new release should come with at least an increment of the ```Minor``` component. Individual commits and development builds might not get individual versions assigned (they might only differ in their build metadata, ex. build number, date, etc.).
|
Loading…
Reference in New Issue