0.10 | 0.X What's in a version name?
16 comments
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.
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?
You should name it 0.10, like almost every other project would. How do you think the linux kernel got to 2.6.25?
After 0.10 comes 0.11. Similarly, after FreeBSD 4.10 came FreeBSD 4.11 -- which was unofficially called the "spinal tap" release.
He should make it 0.10, and release a 0.11 the following week, to minimize the period of confusion :p
> Then what would you do when you got to version 11?
0.XI?
0.XI?
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.
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.
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.
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.
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.
Next you'll advocate that 1k should be 1000 bytes because 1024 is not intuitive to normal folks.
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.
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.
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.
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.
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.
My employer uses the same version scheme for all products: rXpY-revZ, e.g. r2p1-rev7.
I like gentoo's versoning system which is based on the year.number. less confusing. you could use the full date too.
0.10
You've got a plan, stick to it.
You've got a plan, stick to it.
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.
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.
this is the color of the bikeshed
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?