1 files changed, 92 insertions, 0 deletions
diff --git a/src/process:versioning_schemes.ascii b/src/process:versioning_schemes.ascii
new file mode 100644
index 0000000..53b76e9
--- /dev/null
+++ b/src/process:versioning_schemes.ascii
@@ -0,0 +1,92 @@
+Process:Versioning Schemes
+==========================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+:revdate: May 08, 2017
+
+== {doctitle}
+
+I have been on the hunt for a while for a good versioning scheme that's
+flexible enough to meet the needs of multiple teams, not be too complex, and
+also not have enormous numbers right out of the gate (*hint hint*, like the
+number 53 - you know who you are).
+
+I really like how the Linux kernel does its general release management, so this
+is slightly taken from them, as well as Crux Linux package versioning.
+
+That said, versioning schemes are a very opinionated matter, from no
+versioning, to date built, all the way to just using a build number (which
+quickly reaches into the thousands if you do CI and CD - a new build and new
+version per commit effectively).
+
+That said, let's get to the details.
+
+
+The Scheme
+----------
+
+This versioning scheme has three (well, kind of four) digits. It looks like...
+
+[width="50%"]
+|===
+|    X. |     X. |      X
+| major | minor  | hotfix
+|===
+
+
+The first digit, 'major', is obviously the major version. It should rarely
+increment unless there is a huge change in the software or you decide your
+minor version is just too big (how's that for arbitrary).
+
+The second digit, 'minor', is the version that should increment for each new
+release cycle. Depending on how fast your release cycles are, you will reach
+well into the tens on this on before incrementing the major digit.
+
+The last digit, 'hotfix', should almost always be *0*. Originally this scheme
+was two digits, but that doesn't account for a world where not every unit,
+smoke, and integration test is written (which is most teams I think) and
+something is missed. It also doesn't account for managers who can't tell
+customers to wait for the next cycle. This digit is for those scenarios when
+you've done a complete release, to production, but need to do a hotfix release.
+If you ever need to go above 1 or 2 on this digit, you're probably doing it
+wrong and should see a couselor about your boundary issues.
+
+
+
+The Forth Digit
+---------------
+
+As mentioned, there is possibly a 4th digit (if you feel the need for it). This
+digit is not for the software developers, but for the deployment team, so it's
+quite optional in most cases I think. This should always be 0, unless the
+deployment team needs to make changes to the deployment process contained
+within your package (usually configs and whatnot). Arguably though, if you're
+storing deployment configurations next to your application code, you might be
+doing it wrong (though that's very subjective).
+
+With that, this is a very optional digit.
+
+
+[width="50%"]
+|===
+|    X. |     X. |     X. |      X
+| major | minor  | hotfix | package
+|===
+
+
+The Real World
+--------------
+
+In application, this should solve all the problems mentioned at the start of
+the post. Throw on a '-rcX' to the end and you'll have a release candidate
+process (much like the Linux kernel) for your higher level testing environments
+without needing to change your versioning scheme. You can even create git tags
+that match!
+
+Writing this post has been quite the release! (sorry - I had to make the pun)
+
+
+[role="datelastedit"]
+Last edited: {revdate}
+
+// vim: set syntax=asciidoc: