HN Explorer

0.10 | 0.X What's in a version name?

5 points by mcormier ↗ HN
I am writing software that is currently at a 0.9.1 version number with the format of <Major release>.<release>.<bug-fix>.

I increment the release number when new features are added. The next release, although I am getting close to a 1.0 would be labeled 0.10 with that rationale. Personally I'm not big on the label 0.10 because 0.10 and 0.1 look very similar although there are 9 releases in between them. I wouldn't want someone that is scanning text quickly to think, oh it's the first release, when in fact it is the tenth.

I have been considering releasing the tenth release as 0.X to alleviate this problem but this seems quite unconventional.

Thoughts?

16 comments

[ 1154 ms ] story [ 5326 ms ] thread
mark-t
Then what would you do when you got to version 11? You'd have to wait for Apple to figure it out.

You should name it 0.10, like almost every other project would. How do you think the linux kernel got to 2.6.25?

alex_c
He should make it 0.10, and release a 0.11 the following week, to minimize the period of confusion :p
cperciva
After 0.10 comes 0.11. Similarly, after FreeBSD 4.10 came FreeBSD 4.11 -- which was unofficially called the "spinal tap" release.
xirium
> Then what would you do when you got to version 11?

0.XI?

ra
0.10

You've got a plan, stick to it.

gojomo
0.X is so unconventional as to be nutty and confusing.

You could skip to 0.11 or 0.99. Numbers are free.

You could get over your "1.0.0" anxiety and just call it "1.0.0", knowing you'll have a "1.0.1" or "1.1.0" or "2.0.0" soon enough. Numbers are free and expectations of polish (especially if it's freely-available and net-related) in early releases are lower than ever.

SnowLprd
0.10.0 is really messy for most people -- people who are very different from the target market for packages like Linux and FreeBSD and who are not accustomed to such notation. I think you should simply make an exception to your normal release pattern and use 0.9.2 for your next release. Either that, or make the jump to 1.0.0.
Hexstream
Next you'll advocate that 1k should be 1000 bytes because 1024 is not intuitive to normal folks.
SnowLprd
No, actually, I won't. Bytes aren't forward-facing -- if you aren't a propellor-head, you don't really need to know that there are 1024 bytes in a kilobyte. Version numbers are forward-facing.

Besides -- for most software -- if you introducing so many new features that you are exceeding ten point releases without a new major release... then something else is wrong. Time to re-think the release management strategy.

mark-t
That might be accurate for shrink wrap software and maybe even shareware, but it's not for free (as in beer) software. I'll grant that it was never specified, but I got the impression this project was being freely distributed -- otherwise he probably wouldn't bother with bugfix releases.

In the free (as in speech) software world, major versions indicate major changes in the software (e.g. gtk+1 vs. gtk+2). A series of minor features, no matter how long, doesn't warrant a new major release number.

icey
It's time for me to put on my "unpopular things to say" hat. Pick a version number and move on. Nobody will care as much about it as you do. I'm sure you have bigger problems to solve. Its your software, do with it as you please.
johnm
Do the version numbers actually indicate anything to the users? I.e., are you really so disciplined that e.g.: bugfix releases are always transparently compatible, minor version updates are forward and backward compatible (within their major version), and major version changes are backward compatible? Most uses of that format is a delusion of precision.

I've seen very, very few projects that are that disciplined. So, you might as well just use something like a date, 20080521, or a YYYY.Release# approach.

silencio
Following in Apple's footsteps? ;) To this day I still have friends who call it "Mac OS X" instead of "Mac OS 10", not realizing it's actually a version number..and it's been what, 10 years? It doesn't help that Apple often advertises it as "Mac OS X version 10.(whatever)".

If you're not ready for a 1.0 and you don't like the 0.10 number, just keep the 0.9.x version number until you are. Or skip 0.10 and go to 0.11 which might be slightly less confusing because the zero isn't there?

Personally I agree with you. Sometimes it's confusing because 0.10 looks like 0.1.0 or sometimes 0.1.

wlievens
You could (but it's probably too late for that) not use dots as separators.

My employer uses the same version scheme for all products: rXpY-revZ, e.g. r2p1-rev7.

jsomers
this is the color of the bikeshed
xenoterracide
I like gentoo's versoning system which is based on the year.number. less confusing. you could use the full date too.