178

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.

Noarth
  • 3,981
  • 6
  • 23
  • 16
  • 3
    I just found out about "semantic versioning" (http://semver.org/), that's pretty much what I want to do. However, I'm not creating APIs and it's talking about APIs, so the 1.0.0 advice doesn't really apply. – Noarth Sep 16 '10 at 16:58
  • Similar to: http://stackoverflow.com/questions/1795920/how-do-other-development-teams-approach-version-numbers/1795940#1795940 – Fiona - myaccessible.website Sep 16 '10 at 17:00
  • possible duplicate of [Should a first release be an 0.1 version or 1.0b?](http://stackoverflow.com/questions/7139/should-a-first-release-be-an-0-1-version-or-1-0b) – Ricardo Gladwell Jan 21 '14 at 15:49

11 Answers11

346

The Semantic Versioning 2.0.0 standard provides the 0.y.z space to indicate that your project does not have a stable public API:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

It is suggested to start at 0.1.0 and bump the minor version on every breaking change to the public API. You can increment to 1.0.0 when you are in a position to appropriately control and manage these breaking changes:

Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

The benefit of using the 0.y.z space is that you will not reach a high major version, e.g. 142.6.0, during initial development. It tends to be industry convention to avoid high major version numbers, partially for marketing reasons, but this may not be relevant to you.

Semantic Versioning applies specifically to projects with public APIs, but is often applied in other contexts with an alternative notion of "breaking change", e.g. large changes to GUI interfaces.

Bardi Harborow
  • 1,803
  • 1
  • 28
  • 41
  • There is a pitfall if you using npm. If you start with 0, caret sign "^" in package.json will behave different. https://docs.npmjs.com/misc/semver#caret-ranges-123-025-004 You can use 0.x instead of ^0. in package json for this scenario. Therefore, 1.x is a bit more easy to start and use. – Sam Mar 30 '20 at 11:23
  • 1
    I want to challenge the notion that `142.6.0` is "silly". I think I understand the spirit of what you said: that the industry convention is to keep the major version low and have it change relatively infrequently. But it's just that - a convention. One that's actually harmful because it brings subjectivity into what should be an otherwise purely logical process. Was a breaking change introduced? Bump the `MAJOR` version, no edge cases to try and keep track of. Comments and challenges welcome, always open to learn :) – Alex Alksne Aug 19 '20 at 18:27
  • 3
    @AlexAlksne I reworded this somewhat to make it a little milder. :) – Bardi Harborow Apr 23 '21 at 21:21
18

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.

Escualo
  • 40,844
  • 23
  • 87
  • 135
  • 1
    I believe this is sometimes called [Sentimental Versioning](http://sentimentalversioning.org/). Developed with the aim of creating *"beautiful versions"*. – Annan Yearian Oct 26 '22 at 10:07
6

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.

Alexandre C.
  • 55,948
  • 11
  • 128
  • 197
2

When choosing version numbers for an npm package, be aware that for dependencies listed in package.json semver ranges won't work below v1.0.0. That is,

"dependencies": {
    "my-package": "^0.5"
}

is equivalent to

"dependencies": {
    "my-package": "0.5"
}

If you want to be able to use semver ranges, or you want to let other people use them, you might want to start with 1.0.0

henry
  • 4,244
  • 2
  • 26
  • 37
  • 1
    Interesting. Do you have more information on why (or where) Semver ranges don't work below 1.0.0? Since there are quite some packages using `0.0.x` in the [npm registry](https://www.npmjs.com/). – Remi Mar 12 '18 at 10:59
  • I don't know why the npm folks made that decision, or where in the npm system it's made / what would need to change to support semver ranges for versions less than 1. I'd be interested to know too! – henry Mar 12 '18 at 17:53
  • 3
    They made that decision because [`^` means "compatible with version"](https://docs.npmjs.com/files/package.json#dependencies). More details [here](https://docs.npmjs.com/misc/semver#caret-ranges-123-025-004). In semver, `0.y.z` is meant for initial development and any change in `y` or `z` can be backwards incompatible. In your example, `^0.5 := 0.5 := 0.5.x`, so it is a range. If the caret range doesn't work for you in the `0.y.z` range, you can use comparator, hypen, x, and tilde ranges, in addition to caret ranges. – dosentmatter Apr 25 '18 at 03:22
1

0.1.0 is what I start with and move up from there. This is what I've adapted for Xploration By Adrian, although in my early years I was very sporadic and used 1.0.0, 0.0.1, and a few others. But I do recommend starting at 0.1.0 and going from there.

Per Semver, reserve a and c in a.b.c for A. You first official release and C. Bug fixes and patches. This is because a major version generally breaks older code. And patches simply fix bugs. This is all personal preference, 0.99.0 doesn't mean you have to go to 1.0.0, etc. I've seen some that go all the way to 0.218.42.

TheGrimSilence
  • 47
  • 9
0

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.

Michael Venable
  • 5,011
  • 3
  • 23
  • 20
0

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 :).

aib
  • 45,516
  • 10
  • 73
  • 79
  • I see this mistake often: people think that just because a version number contains a `.`, they treat it as a decimal and think that `1.0` must follow `0.9` when in fact `0.10` could be the next version. The `.` is a version component separator rather than a decimal point and each component has its own meaning which determines whether or not it should change. – Matt Arnold Jul 27 '23 at 15:43
-1

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.

Community
  • 1
  • 1
Icarin
  • 427
  • 5
  • 7
-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

Tristan
  • 3,845
  • 5
  • 35
  • 58
  • 4
    That somehow implies that you can only go as far as 0.9.0, but I know a lot of projects that go on like 0.25.0. – Noarth Sep 16 '10 at 16:36
  • I tend to use the last set of digits for minor incremental changes as well as bug fixes, and keep the middle set of digits for fairly major changes so never really have the need to go into double digits for the middle numbers – Tristan Sep 16 '10 at 16:42
-3

start with 0.0.0 and move on from there.

warsong
  • 1,008
  • 2
  • 12
  • 21
  • 4
    Does that mean you would actually do a 0.0.0 release? I'm starting with the first number that I'm going to release. – Noarth Sep 16 '10 at 16:32
  • I second this - versions are supposed to represent changes to a released assembly. If there have been no Major, Minor, (Patch|(Build.Revision)) changes then logically your 1st release of that assembly would be `0.0.0` (or `0.0.0.0`) since there have been zero changes to all of these components. – Matt Arnold Jul 27 '23 at 15:52
-16

Start with 1.1.1 and move on from there.

High Performance Mark
  • 77,191
  • 7
  • 105
  • 161