Release Names vs. Numbers

Let’s talk about release numbers. They’ve been around forever in the software world, and I get why—they help developers keep track of changes, manage dependencies, and make sense of updates. But honestly, as projects get bigger and more complicated, I feel like release numbers lose their meaning, especially when teams start using them as milestones to plan their next steps.

Here’s my take on why release numbers aren’t always the best fit and why I think release names might be a better option.

The Problem with Version Numbers

You’ve seen it before: a new release drops with a version number like 2.4.3 or 3.0.0. If you follow semantic versioning, you know what those numbers mean:

• 2.4.3: The second major release, the fourth minor update, and the third bug fix.
• 3.0.0: A shiny, big update with major changes.

And that’s fine… for developers. But problems start popping up when you use version numbers to plan the future:

1. Inflexibility:

Version numbers lock you into rigid expectations. If you’re aiming for a “major” release, you might feel pressured to cram in extra features to justify the version bump. Or worse, you delay the release to make it “worthy” of that next big number.

2. Miscommunication:

Let’s be real—non-technical people don’t care about version numbers the way developers do. A “3.0” release might sound revolutionary, but what if it’s just a new logo and some performance tweaks? That’s underwhelming, right?

3. It’s Just Marketing:

Deciding what makes a release “major” or “minor” can get pretty arbitrary, especially for something like a blog or any project that evolves continuously. After a while, the numbers start to feel more like branding than anything meaningful.

Why Release Names Make More Sense

So instead of numbers, why not use names? Names aren’t just easier to remember—they also make your planning and communication way more flexible. Here’s why I love this idea:

1. Flexibility Over Numbers

Imagine your last release was called Betty - 2.4.3. Instead of stressing over whether the next release should be a 2.5.0 or 3.0.0, you just call it Charley. It doesn’t matter if Charley ends up being a bug fix or a major overhaul. You decide what goes into the release as you go.

2. Easier to Remember

Ubuntu has nailed this with release names like Trusty Tahr and Focal Fossa. Android did it with dessert names like Oreo and Pie. These names stick. They’re fun, they’re memorable, and they give each release a bit of personality.

3. Better for Agile Planning

Names let you stay flexible. If priorities change mid-project, it’s not a big deal. You don’t have to scramble to justify a version bump—you just work on getting Charley done and assign the version number later.

4. Adds a Personal Touch

Names make releases feel less like cold, technical updates and more like milestones people can get excited about. For example, Android Lollipop feels a lot more engaging than Android 5.0.

How I Use This in The HomeLab

For my personal project, The HomeLab, I’ve completely skipped version numbers. Every sub-project gets its own name. Once it’s done, it’s done. There’s no HomeLab 1.0 turning into HomeLab 2.0. Progress isn’t measured by numbers—it’s measured by what gets delivered.

Where Version Numbers Still Matter

That said, version numbers aren’t going away anytime soon, and for good reason. They’re still crucial in technical environments:

• For Developers: Version numbers help track meaningful changes. A major version bump might indicate breaking changes to an API, so other developers know to check for compatibility.
• For Dependency Management: Tools like package managers and CI/CD pipelines rely on these numbers to keep everything in sync.
• For Automation: Versioning makes automation workflows possible—think of how many systems flag updates or handle rollbacks based on version numbers.

But here’s the thing: version numbers should be assigned after the fact, based on what actually changed. They shouldn’t be used for stakeholder communication or to set expectations about what’s coming next.

Conclusion

For planning and communication, release names just make more sense. They’re flexible, easy to remember, and way better for staying agile in a fast-paced world. Numbers, on the other hand, work best in the technical backend, where precision and compatibility are the priority.

For me, ditching version numbers has been freeing. It’s one less thing to overthink. Instead, I focus on the work and let the results speak for themselves.

homelab