93 <chapter> |
93 <chapter> |
94 <name>Semantic versioning</name> |
94 <name>Semantic versioning</name> |
95 <id>aa8bd952-842b-4391-aefe-d9b3750e432d</id> |
95 <id>aa8bd952-842b-4391-aefe-d9b3750e432d</id> |
96 <item> |
96 <item> |
97 <id>a8beddfc-11e3-4012-9f88-f79dc88eee16</id> |
97 <id>a8beddfc-11e3-4012-9f88-f79dc88eee16</id> |
98 <text>Semantic versioning is strongly recommended.</text> |
98 <text>Semantic versioning is required.</text> |
|
99 <text>The version number consists of three numbers: major.minor.pach.</text> |
|
100 <text>Major version is incremented if there is an incompatible change.</text> |
|
101 <text>Minor version is incremented if a feature is added in a compatible way.</text> |
|
102 <text>Patch version is incremented if a bug is fixed in a compatible way.</text> |
99 <note>see http://semver.org/</note> |
103 <note>see http://semver.org/</note> |
100 </item> |
104 <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> |
101 <item> |
105 <note>Propper Semantic versioning is especially important if the software is suposed to be used as dependency by others.</note> |
102 <id>a8ef6602-cd90-4b42-932e-fce76b2d312a</id> |
106 <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> |
103 <text>Especially when the software is suposed to be used as dependency by others.</text> |
|
104 </item> |
|
105 <item> |
|
106 <id>f1c461d6-1f3c-43f0-b16d-65c5bac9b0b5</id> |
|
107 <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> |
|
108 </item> |
107 </item> |
109 <item> |
108 <item> |
110 <id>cf557a11-b307-4c2f-a7b5-5d2485d23258</id> |
109 <id>cf557a11-b307-4c2f-a7b5-5d2485d23258</id> |
111 <text>Once publicly released, the package must not be changed anymore – if a change (even a small fix) is needed, new version number must be assigned.</text> |
110 <text>Once publicly released, the package must not be changed anymore – if a change (even a small fix) is needed, new version number must be assigned.</text> |
112 </item> |
111 </item> |
113 <item> |
112 <item> |
114 <id>dd013325-bf22-43d3-9579-0e272e2ac344</id> |
113 <id>dd013325-bf22-43d3-9579-0e272e2ac344</id> |
115 <text> |
114 <text>APIs, file formats and protocols might (and usually should) be semanticly versioned independently from the implementation.</text> |
116 APIs, file formats and protocols might (and usually should) be semanticly versioned independently from the implementation; |
115 <note>In such case, there should be a table documenting which API/format/protocol version matches which implementation version.</note> |
117 in such case, there should be a table documenting which API/format/protocol version matches which implementation version. |
116 </item> |
118 </text> |
117 <item> |
|
118 <id>dacb98cc-b558-4f0e-942d-e12004e45606</id> |
|
119 <text>The branching model in the version control system should reflect the semantic versioning.</text> |
|
120 <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> |
|
121 <text>Where the v_2.3 branch was forked from the v_2 branch – from the v2.3 tag.</text> |
119 </item> |
122 </item> |
120 |
123 |
121 </chapter> |
124 </chapter> |
122 |
125 |
123 <chapter> |
126 <chapter> |