1 Process:Versioning Schemes
2 ==========================
3 :author: Aaron Ball
4 :email: nullspoon@iohq.net
5 :revdate: May 08, 2017
6
7 == {doctitle}
8
9 I have been on the hunt for a while for a good versioning scheme that's
10 flexible enough to meet the needs of multiple teams, not be too complex, and
11 also not have enormous numbers right out of the gate (*hint hint*, like the
12 number 53 - you know who you are).
13
14 I really like how the Linux kernel does its general release management, so this
15 is slightly taken from them, as well as Crux Linux package versioning.
16
17 That said, versioning schemes are a very opinionated matter, from no
18 versioning, to date built, all the way to just using a build number (which
19 quickly reaches into the thousands if you do CI and CD - a new build and new
20 version per commit effectively).
21
22 That said, let's get to the details.
23
24
25 The Scheme
26 ----------
27
28 This versioning scheme has three (well, kind of four) digits. It looks like...
29
30 [width="50%"]
31 |===
32 | X. | X. | X
33 | major | minor | hotfix
34 |===
35
36
37 The first digit, 'major', is obviously the major version. It should rarely
38 increment unless there is a huge change in the software or you decide your
39 minor version is just too big (how's that for arbitrary).
40
41 The second digit, 'minor', is the version that should increment for each new
42 release cycle. Depending on how fast your release cycles are, you will reach
43 well into the tens on this on before incrementing the major digit.
44
45 The last digit, 'hotfix', should almost always be *0*. Originally this scheme
46 was two digits, but that doesn't account for a world where not every unit,
47 smoke, and integration test is written (which is most teams I think) and
48 something is missed. It also doesn't account for managers who can't tell
49 customers to wait for the next cycle. This digit is for those scenarios when
50 you've done a complete release, to production, but need to do a hotfix release.
51 If you ever need to go above 1 or 2 on this digit, you're probably doing it
52 wrong and should see a couselor about your boundary issues.
53
54
55
56 The Forth Digit
57 ---------------
58
59 As mentioned, there is possibly a 4th digit (if you feel the need for it). This
60 digit is not for the software developers, but for the deployment team, so it's
61 quite optional in most cases I think. This should always be 0, unless the
62 deployment team needs to make changes to the deployment process contained
63 within your package (usually configs and whatnot). Arguably though, if you're
64 storing deployment configurations next to your application code, you might be
65 doing it wrong (though that's very subjective).
66
67 With that, this is a very optional digit.
68
69
70 [width="50%"]
71 |===
72 | X. | X. | X. | X
73 | major | minor | hotfix | package
74 |===
75
76
77 The Real World
78 --------------
79
80 In application, this should solve all the problems mentioned at the start of
81 the post. Throw on a '-rcX' to the end and you'll have a release candidate
82 process (much like the Linux kernel) for your higher level testing environments
83 without needing to change your versioning scheme. You can even create git tags
84 that match!
85
86 Writing this post has been quite the release! (sorry - I had to make the pun)
87
88
89 [role="datelastedit"]
90 Last edited: {revdate}
91
92 // vim: set syntax=asciidoc:
|
