A lot of software updates follow the scheme of v0.1 to v0.2 to v2.6.5.6. What do these "updates" to software really mean? Is there an industry standard always followed or do programmers pretty much keep raising the update # or adding more decimals?
-
12@S.Lott As I'm fairly new to the programming scene I wouldn't know specificities. This is the best way of asking that I could come up with.– James MertzFeb 14, 2011 at 2:17
-
9@S.Lott, cut back on the caffeine sir, it's making you irritable.– ocodoFeb 14, 2011 at 2:45
-
2@S.Lott feel free to edit as you see fit to better the question. I feel that you know what I'm looking for. However, I do feel that the answers provided have been very good. I also feel, judging by the up-votes on my previous comment, that I've done the best that I can and that the question is ok as is. However I welcome criticism, as well as edits. Do as you see fit. For me, I'm leaving it alone.– James MertzFeb 14, 2011 at 15:23
-
1@S.Lott The question seems pretty clear as is to me. I don't think listing a specific standards-writing organization would be a considerable improvement. If you feel otherwise, do feel free to edit. You have the rep for it.– Adam Lear ♦Feb 14, 2011 at 15:47
-
3@S.Lott: "Is there an industry standard" is completely fine. Yes, there are industry standards! It doesn't matter who writes them: KronoS wants to know what versions mean, it is his choice to specify how detailed he goes... Perhaps you should have mentioned that you deem the question to broad? Just hammering on details doesn't make that clear to the user, telling a user to define:word doesn't make that clear to the user, telling it is meaningless after your first comment doesn't make that clear to the user.– Tamara WijsmanFeb 14, 2011 at 15:50
4 Answers
Like Shaun said, there isn't really a standard. Some companies have better versioning practices than others (I've dealt with vendors who skip major version numbers, and others that are stuck on the same x.y several releases later).
Having said that, the inventor of Gravatars and cofounder of GitHub (Tom Preston-Werner) authored a document for 'Semantic Versioning' which is more than worth a read.
Here's the except of the intro:
As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.
I call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.
With 4 digits it is usually MajorV.MinorV.PatchNum.BuildNum, at least where I work.
I personally prefer the Ubuntu's versioning scheme - makes life so much easier.
-
-
3Ubuntu 10.10 = October 2010, Ubuntu 10.04 = April 2010, Ubuntu 11.04 = Aprial 2011, Ubuntu 9.10 = October 2009, etc. This is mentioned in that Wikipedia link by Shaun.– JobFeb 14, 2011 at 1:54
-
2The nice thing about using dates as version numbers is that -- unless some wierd time paradox happens -- your version number will always be in the correct order. For most of us, it's easier to remember that today is 2011.02.13 than it is to try to figure out what version of the new release should be.– jmort253Feb 14, 2011 at 3:07
-
@jmort245, Exactly! Man-made systems are quite messy. Freaking banks think that there are 360, 362, 365, 366, etc. days in a year. Versioning system is yet another one of those stupid creations. Timestamps do not make us think, although 20050207 takes a bit longer to read and figure out than 502. What software is released more often than once per month?– JobFeb 14, 2011 at 3:27
-
2@job: But using versions allows you to tie features to specific major or minor versions. So If I have version 2 I know that I have feature X while version 1 does not have version X. Feb 14, 2011 at 5:34
The short version is that there is no standard and companies do whatever they want. Essentially, the more numbers you have, the smaller the amount of changes each number represents. Commonly, you'll see at least version x.y, where x a change in x signifies major releases (major enhancement/feature rollouts) and y signifies minor releases (significant tweaks or defect fixes). More decimals after those two can mean different things internally to a company although often revolve around minor content builds or patches that represent quicker and smaller fixes.
Wikipedia has an article that covers this in greater detail.
The purpose of version numbers is to provide a reference for problem reports. The only requirement is that every release has a unique version number. Some numbers are driven by marketing--bigger whole numbers are easier to sell, and power numbers like 10 (roman numeral X) are really catchy. Some people use some variation of semantic versioning:
MAJOR.MINOR.MICRO.BUILD
- Major increments: incompatible changes or complete redesign of the UI
- Minor increments: new features added, compatible with prior versions in the same major version number
- Micro increments: bug fix release
- Build number: generated by the compiler or pulled from version control
Many groups drop the BUILD number in their releases. It's usually only useful between testing and development groups.
Some groups add additional semantics, such as odd numbered MINOR increments are for experimental builds and even numbered MINOR increments are for production releases (Linux kernel uses this approach).
Bottom line is that there is no standard, other than newer versions use higher version numbers, and that each version number is unique.