# HG changeset patch
# User František Kučera <franta-hg@frantovo.cz>
# Date 1569067891 -7200
# Node ID 893043da854c04bac6cdc6569929630826022fac
# Parent  2c064ad964cd24bc96bdb02992a90aad3e831f64
Semantic versioning is required

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 @@
 		<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>