Wrote Process:Versioning Schemes

This post details what is (hopefully) a useful, flexible versioning
scheme that other people can use (it's a very subjective matter, so
quite possibly not).

Updated index.php. Added new post to 'New Posts' section and removed
another.

2 files changed, 98 insertions, 1 deletions

diff --git a/src/index.ascii b/src/index.ascii
index e3dfc28..6e8c1c8 100644
--- a/src/index.ascii
+++ b/src/index.ascii
@@ -8,6 +8,7 @@ Index
 
 New Posts
 ~~~~~~~~~
+* link:?p=process:versioning_schemes[Process:Versioning Schemes]
 * link:?p=bash_mock_objects_commands[Bash Mock Objects/Commands]
 * link:?p=linux_development:detecting_stdout_escape_char_support[Linux Development:Detecting STDOUT Escape Char Support]
 * link:?p=linux_desktop:password_management[Linux Desktop:Password Management]
@@ -16,7 +17,6 @@ New Posts
 * link:?p=linux:manual_restart_with_sysrq-trigger[Linux:Manual Restart with sysrq-trigger]
 * link:?p=crux_linux:faster_builds[Crux Linux:Faster Builds]
 * link:?p=understanding_the_bash_fork_bomb[Understanding the Bash Fork Bomb]
-* link:?p=gentoo:kernel_cleanup[Gentoo:Kernel Cleanup]
 
 
 Linux
@@ -172,6 +172,11 @@ Open Source
 * link:?p=Using_SpiderOak_with_Qt_4.7.2[Using SpiderOak with Qt 4.7.2]
 * link:?p=Theming_Gnome-Shell_Intro[Theming Gnome-Shell Intro]
 
+Processes
+~~~~~~~~
+* link:?p=process:versioning_schemes[Process:Versioning Schemes]
+
+
 
 Generic Troubleshooting
 ~~~~~~~~~~~~~~~~~~~~~~~
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: