# Software versioning hype



## graudeejs (Jun 10, 2012)

Looks like ever since chrome became open source, a new software versioning hype appeared. Look at Firefox. It's already v13 out there (version 3.6 was released on January 2010). Today I checked linux.com, and oh-la-la, Linux kernel 3.4 coming out soon.

It's funny how slowly Linux version numbers changed in the past and now they skyrocket. Just about a year ago there was Linux 3.0, which was major change from 2.6.x.x now they try to catch up Microsoft Windows 8 (joking).

I find it silly and ridiculous.


----------



## drhowarddrfine (Jun 10, 2012)

In the case of browsers, it's not hype. I've seen a couple of people think it's all marketing but that has nothing to do with it. 

A new trend called "rapid release" in software has come about because major version number changes were based on large, major changes to the software, but that was holding back smaller changes. For example, people complained about Firefox 4 taking a long time to come out with badly needed updates. It was late over a year. What held it back was just one major item but there were hundreds of other changes ready to go and no reason they couldn't be implemented. That one change was all that held FF4 and all those improvements from being released.

So major version numbers are no longer based on any one major change. Chrome does the same thing. And IE is implementing that in IE10 (though no one should be using IE and IE will still be on a yearly update basis unlike the other far more modern browsers...but I digress).


----------



## Zare (Jun 11, 2012)

It's easier to use timestamps then - Firefox release 20120611.


----------



## expl (Jun 11, 2012)

Timestamp does not provide any information regarding the change nature what so ever. In versioning numbers you can see compatibility changes and if the change contains bug/security fixes also versioning numbers can be branched while timestamp can only represent a single branch.

Imagine the chaos if FreeBSD was versioned with a timestamp .


----------



## mix_room (Jun 11, 2012)

expl said:
			
		

> Timestamp does not provide any information regarding the change nature what so ever.


Which is what the release note should be for. The version number by itself does not provide this information either. You imply some of the information, but you do not have it. 



> In versioning numbers you can see compatibility changes and if the change contains bug/security fixes


Where do you see compatability changes between version 8 and version 9? By convention you assume that 17.4 will be compatible with 17.2, but you have no way of knowing this. 



> Imagine the chaos if FreeBSD was versioned with a timestamp .


Which in a sense it does when you run a development version. Revision number is not much more than a timestamp. 

Running more than one branch is not a problem either. You just release each branch with a different prefix. Branch1 - 201206XX, Branch2 - 201108YY

In the end I believe it depends on whether you are a user or a developer. Developers imply a pattern in the version numbers, hence they contain some information, for the user the new increasing counter variant is just as good. If my version number is lower than the one available I know that I should update. If I then additionally have the release date I can tell how old my program is. Perhaps this would lead people to update a little more often. "My my, my ToolX is from 2007ZZZZ"


----------



## SirDice (Jun 12, 2012)

graudeejs said:
			
		

> Looks like ever since chrome became open source, a new software versioning hype appeared.


It not something "new". I can remember Slackware going from version 3 to 7 just to keep up with the version numbers of the other distributions.


----------



## funky (Jun 12, 2012)

One notable persiflage of strange version numbering is probably the Tex version number: each new version simply gets an additional digit of Pi, the current version is 3.1415926 .


----------

