Version 1.0

01 Apr 2014

Let the first version number for your project to be 1.0. Assume, you don’t have anything yet besides desire to make something useful to the world. Then, begin with assigning version 1.0 in a README file or a build script. It is an excellent start!

Any version less than 1.0 is always an excuse. You tell people: “I’m not sure, if it is worth it”. If you’re not sure, how can anyone else be sure?

Yes, you’ve done nothing yet, so you assign version 0.1. You hope, that when (or if) there is something, you’ll change it to 1.0. Not so easy. Version will grow, but the longer project will live, the more moral effort it will take to say “yes, it is 1.0”. Many only have courage to jump somewhere closer to the number, e.g. 0.12 -> 0.9. As a result, we have monuments of diffidence such as 11 years, version 0.50a or 17 years, version 0.152.

There will be other reasons, too. If after half a year of development you decide, that the time has come, users will immediately ask “wtf?”. Why this commit fixes a couple of missprints and changes version from 0.5 to 1.0? Nothing really changed, after all! The project hasn’t become notably better or more stable. So, you write a humiliating blog post: “you know, we tinker this for a long time now, so we just think, that it is 1.0 already”. Well, that’s convincing!

You will know, that your project is useful, stable and time-tested. But it’s version is still 0.8.2, and you can’t do anything about it. When potential users stumble upon it in the Web, they ignore it, thinking “well, everything looks OK, but it is still a beta, so I’d better not waste time”.

Version 1.0 from the very beginning is a pledge to yourself and the others, that you’re serious about the project. It gives you more stimuli to not give up, to make something working as soon as possible and support it afterwards.

So, what about versions past 1.0? Do whatever you want, nobody really cares, if it’s 1.0.1 or 1.1. Just don’t forget to assign 2.0 to your “experimental” branch.