🛑Stop Pretending🛑Your Code’s Not Stable
Photo by Denley Photography on Unsplash
I mean come on. When you’re developing your side project (and get rid of the idea of the “hustle”, please) there is seldom a rush to release.
I mean, go ahead with your hobby and post the code on GitHub. I’ll cheer you on from the sidelines.
But why are there more and more projects that initially release with a “v1.0”? I live in the 0.x.y version space, and here is why you should still.
Stability is All
If you want to bring a dependency into your project, even a side project, you need that dependency to be stable, you need to be able to rely on a release being a v1.
Yet some folks decide they want to slap on a v1 and parade their code around like it’s a finished article when it’s anything but. When developers prefer 0.x.y until it’s really done they are practicing that rare developer trait of humility because they are admitting it’s not yet…“done”.
Skipping right to v1.0.0 might make your software look legit but what you are actually doing is rushing to a label when the code doesn’t justify that. If your API isn’t stable, you’re just going to cause other developers' pain and that just isn’t cool.
You Don’t Even Know What You Want
Here it comes. I’m going to say it. You don’t actually know what you want in version 1.
You are Netflix wanting to ship VHS tapes trough the post. Since it’s your hobby project you don’t have clearly defined ACs, you don’t even have a set of features in mind.
Until your code has its tires kicked by users and pull requests created by other developers around the world it’s not fit to be a v1.
The arrogant rush to v1.0.0 means just one thing. Future headaches when you realized that software architects do actually do something. More mature developers know that sticking with 0.x.y gives everyone a clear signal — “I’m still figuring this out, and there will likely be breaking changes.”
Versioning is Communication
Version numbers are in themselves a communication tool.
Calling something v1.0.0 when it’s a work in progress is like saying I’m practicing LeetCode challenges right now. When you are disingenuous about the state your code is in, you’re setting your users up for a frustrating experience, and doing so knowingly is just wrong.
You want your users to be with you on the journey, not baying for your blood at each new version.
So instead of skipping to a shipping version, take your time. Use versioning as a communication tool. You’re still evolving and improving and not yet locked into poor decisions.
In the End…Release
I do think you should get to v1.0.0 eventually. neovim’s perpetual 0.x.x status isn’t helpful either as I’m guessing that they are never going to get to the “full” release. Because releasing a new major version is also just fine.
Developers should have the flexibility and room to innovate and communicate with users just what is going on. We all use software as well as create it, so play nice.
Version v1.0.0 indicates the public API, according to the semantic versioning spec (v1.0.0!). Just saying. You should be able to get there in the end.
Conclusion
Next time you’re about to hit the release button take a minute to think. Is this a complete, releasable version? Or are you trying to signal that this is v1.0.0 while it is still a work in progress?
You want to be able to enjoy the moment of “I’m done” when it’s valid and not before. It will be worth more then.