diff -r 2c064ad964cd -r 893043da854c ssm.en.xml
--- a/ssm.en.xml Sat Sep 21 01:17:44 2019 +0200
+++ b/ssm.en.xml Sat Sep 21 14:11:31 2019 +0200
@@ -95,16 +95,15 @@
aa8bd952-842b-4391-aefe-d9b3750e432d
-
a8beddfc-11e3-4012-9f88-f79dc88eee16
- Semantic versioning is strongly recommended.
+ Semantic versioning is required.
+ The version number consists of three numbers: major.minor.pach.
+ Major version is incremented if there is an incompatible change.
+ Minor version is incremented if a feature is added in a compatible way.
+ Patch version is incremented if a bug is fixed in a compatible way.
see http://semver.org/
-
- -
- a8ef6602-cd90-4b42-932e-fce76b2d312a
- Especially when the software is suposed to be used as dependency by others.
-
- -
- f1c461d6-1f3c-43f0-b16d-65c5bac9b0b5
- If there is a need of some marketing or cool versioning/codenames like Ultrasonic Umbrella or 2016, they should be used in addition to semantic versioning, not instead of it.
+ If authors are unable to distinguish between compatible and incompatible changes, they must always increment the major version. However this approach is not recommeded
+ Propper Semantic versioning is especially important if the software is suposed to be used as dependency by others.
+ If there is a need of some marketing or cool versioning/codenames like Ultrasonic Umbrella or 2016, they should be used in addition to semantic versioning, not instead of it.
-
cf557a11-b307-4c2f-a7b5-5d2485d23258
@@ -112,10 +111,14 @@
-
dd013325-bf22-43d3-9579-0e272e2ac344
-
- APIs, file formats and protocols might (and usually should) be semanticly versioned independently from the implementation;
- in such case, there should be a table documenting which API/format/protocol version matches which implementation version.
-
+ APIs, file formats and protocols might (and usually should) be semanticly versioned independently from the implementation.
+ In such case, there should be a table documenting which API/format/protocol version matches which implementation version.
+
+ -
+ dacb98cc-b558-4f0e-942d-e12004e45606
+ The branching model in the version control system should reflect the semantic versioning.
+ The released version e.g. 2.3.1 should be tagged as v2.3.1 and be placed in the v_2.3 branch.
+ Where the v_2.3 branch was forked from the v_2 branch – from the v2.3 tag.