--- 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 @@
<id>aa8bd952-842b-4391-aefe-d9b3750e432d</id>
<item>
<id>a8beddfc-11e3-4012-9f88-f79dc88eee16</id>
- <text>Semantic versioning is strongly recommended.</text>
+ <text>Semantic versioning is required.</text>
+ <text>The version number consists of three numbers: major.minor.pach.</text>
+ <text>Major version is incremented if there is an incompatible change.</text>
+ <text>Minor version is incremented if a feature is added in a compatible way.</text>
+ <text>Patch version is incremented if a bug is fixed in a compatible way.</text>
<note>see http://semver.org/</note>
- </item>
- <item>
- <id>a8ef6602-cd90-4b42-932e-fce76b2d312a</id>
- <text>Especially when the software is suposed to be used as dependency by others.</text>
- </item>
- <item>
- <id>f1c461d6-1f3c-43f0-b16d-65c5bac9b0b5</id>
- <text>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.</text>
+ <note>If authors are unable to distinguish between compatible and incompatible changes, they must always increment the major version. However this approach is not recommeded</note>
+ <note>Propper Semantic versioning is especially important if the software is suposed to be used as dependency by others.</note>
+ <note>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.</note>
</item>
<item>
<id>cf557a11-b307-4c2f-a7b5-5d2485d23258</id>
@@ -112,10 +111,14 @@
</item>
<item>
<id>dd013325-bf22-43d3-9579-0e272e2ac344</id>
- <text>
- 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.
- </text>
+ <text>APIs, file formats and protocols might (and usually should) be semanticly versioned independently from the implementation.</text>
+ <note>In such case, there should be a table documenting which API/format/protocol version matches which implementation version.</note>
+ </item>
+ <item>
+ <id>dacb98cc-b558-4f0e-942d-e12004e45606</id>
+ <text>The branching model in the version control system should reflect the semantic versioning.</text>
+ <text>The released version e.g. 2.3.1 should be tagged as v2.3.1 and be placed in the v_2.3 branch.</text>
+ <text>Where the v_2.3 branch was forked from the v_2 branch – from the v2.3 tag.</text>
</item>
</chapter>