Why versioning is hard, but a good thing...

Why is it that when you see versioning done well it looks like a no brainer, surely everyone is doing it, and it is well understood by the parties developing the software that is being produced. Well that hasn't been my experience. 

Maybe I'm expecting a little bit too much here, I'm from a developer background, moved into a build engineering / DevOps role to fill a gap in both a company requirement and what was my build and release knowledge. Dev's want to churn out code, release new features and see people use them. That's all well and good however having the whole versioning thing down helps hugely when it comes to trying to manage the product once it's out in the wild. 

Dependencies are another part of this, I'll be talking about java projects but I'm pretty sure this applies to most other programming languages that I've had experience with, such as ruby gems, python packages, node modules, red hat packages (OK, that last one isn't actually a programming language but the principles are the same). 

Release versions are a one time build of your code base at a specific point in time. This is good because I can then rely on that version from a dependency. Furthermore I can be assured that I can develop my code on top of this version and it won't change. This is different to snapshot versions which my definition are not fixed but in a state of flux, but are good for development and getting the latest version. 

I've worked in a number of enterprise companies where versioning (especially of in house artefacts) have been really poor. It's makes such a difference as well, as left out of control your build times can exceed times of 50 minutes in some cases. This breaks the whole reason behind breaking up the code base to smaller independent modules in the first place and ends up in frustration and skipped tests.

Nowadays there really is no excuse for this with lightweight repositories such as git and mercurial and binary package managers like sonatype's nexus and jfrog's artifactory. Coupling that with a build tool, such as maven, ability to create releases, tag SCM and increment versions, the process doesn't have to be laborious. 

With the above it is then possible to start thinking about build pipelines, moving the same version of the code through different environments and eventually pushing that release to production without building it again. Admittedly there are plenty of other things that need to be done before this can be completed but it's a good start.

In reality it seems that versioning and dependency management seems to the the meagre allowance of the few, not the integral knowledge of the many.