What to use as an initial version?

Question

I usually start my projects with a version 1.0.0. As soon as I have some stuff together, I release it as 1.0.0 and move on with 1.1.0.

However, this leads to usable but not exactly feature complete version 1.0.0 of most stuff I write. I then add features and get to a decent version somewhere around 1.6.0. Many projects start with version 0.1.0, which will be as usable as my 1.0.0.

What would you suggest doing? Start with 1.0.0 or 0.1.0?

The last number is for bugfix releases only by the way. You can think of my 1.0.0 as 1.0 and 0.1.0 as 0.1 is that's easier for you.

Answer 1

start with 0.0.0 and move on from there.

Answer 2

When I get my first usable ready but not feature complete version, I normally try to judge how far along it is towards a feature complete version, so for example if my first usable is 33% feature complete I make the version number 0.3.0 or similar. Then as I move towards feature complete corresponding versions get given numbers in a similar way.

But once you move on past feature complete versioning needs to change

Answer 3

Start with 1.1.1 and move on from there.

Answer 4

I think different factors come into play here. Psychological/marketing impact of the version number (version number increased often => more $$$, people don't want to buy a 0.99 beta version, etc) must be taken into account. "Logic" version numbers can help when working in a huge team.

And I like the linux way of having odd numbers for the unstable versions, and even numbers for the stable one.

Answer 5

My versioning is driven by the setup. I want it to replace older versions, so I keep increasing it in jumps that make sense to me.

Sometimes, however, versioning is driven by the customer, especially if you're releasing code to the public.

If it's your call, do whatever works best for you. I've had some issues with versions before 1.0 so I start with that.

Answer 6

The version number is entirely up to you. Do what makes sense to you and be consistent. Nobody says you have to start from 0, or 0.0, or 1.0, or 1.1.

Great programmers have actually used the version numbering system as local jokes. Examples (Wikipedia):

Since version 3, TeX has used an idiosyncratic version numbering system, where updates have been indicated by adding an extra digit at the end of the decimal, so that the version number asymptotically approaches π. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. The current version of TeX is 3.1415926; it was last updated in March 2008

For METAFONT:

Metafont has a versioning system similar to that of TeX, where the number asymptotically approaches e with each revision.

Finally, not quite a version number, but equally interesting, is that Google's initial public offering (IPO) was filed with the SEC for raising $2,718,281,828 (notice that e~2.718 281 828).

My point is: don't feel that you need to follow the crowd. Be creative and consistent.

Answer 7

Typically, the versioning has some meaning to the programmer. Increasing the major number might indicate large changes that prevent backwards-compatibility. Other numbers in the version number might indicate smaller feature enchancements or bug fixes.

If you are worried version 0.6.5 has an incomplete ring to it, you might want to market it under version 1.0. Your marketing version number need not match your internal version number. The version number of Windows 7, for instance, is 6.1.

My personal preference is to start from 0.1.0 and go from there.

Answer 8

Depends on the project. For simple command line tools, I usually start around 0.9[.0] since I only consider releasing or packing them when they're near completion (or ready for beta testing, anyway.) More complicated projects start around 0.1[.0] and some never even see 1.0. I consider 1.0 a release version (or at least a locally tested beta or release candidate) and plan accordingly.

With team projects, whoever puts the first version tag gets to decide :).

Answer 9

The version numbers should be meaning to you as Arrieta correctly commented before.

Maybe following something like: First # is mayor release, Second # is the same mayor release with some features added and Third # is the same mayor release, with the same features but with fixed bugs or added little (but significant enough) changes.

1.3.2 => 1st Release, with more features and some bugs fixed.

However, for final users, some are used to big numbers for final releases.

For instance: Corel 8, for 8.0.0, 8.0.1, 8.2.2, etc. Corel 9, for 9.0.0...etc.

And mostly is more about marketing strategies like: Corel X5 instead of Corel 15.0.2 for instance.

I would say that it depends whether the version number is for you or for the client.