A version number that lied by three releases

The Open Source page on this site lists four packages I built and share publicly, each with a little version badge. v0.6.2, v1.0.0, that kind of thing. I typed those numbers in by hand when I built the page. What I hadn’t done was ever go back and update them.

A review pass pointed out the obvious problem: a hardcoded version on a public page is a promise you have to keep manually, and nobody keeps that promise. I went and checked how bad it was. One of the four was showing v0.6.2. The real published version, the one anyone installing it today would actually get, was three minor releases ahead. The badge wasn’t just stale, it was actively wrong, and had been for a while.

The fix wasn’t computing it

It was deleting it. A version number on a marketing page for an open source package answers a question nobody visiting that page is asking. What they want to know is whether the package exists, what it does, and how to install it. None of that needs a digit.

That last part turned into its own small fix. The install instructions on each package page were showing the exact dependency line this site uses internally - a pinned GitHub tarball URL, because that’s how this site happens to consume its own packages. But these are published to npm now, and nobody evaluating whether to use one wants to see this site’s private plumbing. They want the command they’d actually type. So the install box now shows a plain npm install, with a real link to the npm listing next to the GitHub one.

Lesson

“Make it accurate” and “make it useful” aren’t always the same fix. I could have spent time building a mechanism to keep that version number honest. The honest move was admitting the number never needed to be there - the opposite conclusion from the version badge I did go correct a few days earlier, where the whole point of that page was to say what this site runs.