A brief discussion around the version management of an external project we're dependent on crystallized something for me today.

For some things smarts just isn't enough. Sometimes, smarts isn't even necessary. There is a whole class of problems that are better solved by leaning on experience.

As a concrete example take versioning your source code. Hopefully, it will eventually end up installed in multiple locations. At this point it's going to be important to be able to identify which version is running at a given location (so you can fix it), and to be able to get new versions onto a system (so you can upgrade).

The project I mentioned has deployed version 1.0. Their source code repository currently contains a working branch who's head revision doesn't build and an empty release branch. So we're not really sure where the mythical 1.0 source code lives. It was probably built at a specific revision of the working branch, but which revision is anyone's guess.

From this it seems like, although they're smart, these guys have never been involved in a really long running project. One where multiple versions have to be maintained concurrently. Experience tells me that it's really, really important to be able to do simple things like point at the canonical source code for version 1.0, if only so you can fix the right version when it cocks up and spraypaints someone's poodle deep mauve instead of orange (like they asked).

I feel a bit like some of the "discussions" I've been involved in of late stem from a very theoretical viewpoint, backed by little or no real experience in the problem domain. I don't claim to be the most experienced guy on the block, and by no means do I expect to somehow miraculously avoid any mistakes, but I really feel like I've got enough experience to back up why I'm doing things the way I'm doing them. It won't be perfect, but it has the benefit of having been through the flourmill a few dozen times.