Versions

When building apps and libraries, I tend to be overly pessimistic about dependency versions. I define as much granularity as possible. For apps, this usually means the exact version, including bug or patch level. For libraries, it’s however much specificity I feel I can get away with. I’m pessimistic for a few reasons: I like knowing exactly what version I’m using, and I like the process of upgrading dependencies (i.e. I like running bundle outdated). But I think there’s more to this process.

The concept of versioning is awesome. The reason I like a finite level of control over my upgrading process is because I like the satisfaction that I’ve improved the dependent software, even if I’m just upgrading at the patch level. In a constant pursuit to leave codebases more inhabitable, this is a stark reminder that the work I’m doing makes a difference. Aside from improving codebases, semantic versioning gives a clear indication as to when new features have landed in a library. If bundle outdated tells me I’m a minor version behind, it feels like I’ve struck gold.

This idea translates to user-facing versions as well. I feel remissed that web applications usually don’t surface, and in a lot of cases don’t track, the current version of the software. The same feeling I get when upgrading dependencies I get when upgrading apps on my iPhone. The first thing I do when upgrading is check the changelog, something Apple has made prominent in the App Store. This gives me a sense that someone is improving the app and informs me of new features. In a seamless shipment process for web applications, how can we give users this same sense of personal benefit? It might mean more rigorous practices of tracking and highlighting versions.