|WikiProject Software / Computing||(Rated Start-class, High-importance)|
- 1 untitled
- 2 winamp
- 3 I said "identical" for good reason
- 4 Numeric Versioning
- 5 Disambiguation
- 6 Versioning in general
- 7 version vs revision
- 8 Ubuntu-style version names?
- 9 versioning system != decimal system?
- 10 Skype
- 11 169?
- 12 Do you know an application that use this schema?
- 13 Microsoft's build number is actually an encoded date?
- 14 Firefox 3.0.x?
- 15 How to version your Python projects
- 16 New Versioning Method
- 17 GloboLinux and octal versioning
- 18 Calendar based version numbering scheme
- 19 Time to edit this talk page?
- 20 Parallel versions
- 21 Keeping up with competitors
- 22 It would be interesting to have some history
- 23 what?
- 24 less
In my experience, developers are often unaware that any difference exists between the internal build versions they use for Source Code Management, and the final Release version, which will be used to identify the final version to the customer. They are often unaware of the need for there to be any difference between the two.
Many developers do not seem to be aware that the final "release version" number will be associated with desktop and start menu icons; will be located in the registry; identified in the project name; and be included in any literature which will accompany the product, as well.
I have worked in environments where it was understood that the internal build number was not the same as, nor adequate to be used as the final release version. Yet in other environments, no one seems to see anything wrong with identifying an application as "Application X 2005.15.03 1600". In these environments where an understanding of the differences between internal build versions and final versions does not exist, there is often contention between the developers who want to use their internal build number as the release number, and those parties who are responsible for the final product which gets released.
Although to some, it is common sense that the first release of a product should be identified as "Application X 1.0", with the next release which includes updates being identified as "Application X 1.1", many developers who work daily with only the internal build number see nothing wrong with the first release being identified as "Application X 2005.10.03 1600", with the next release being identified as "Application X 2005.12.04 1200". This is especially true when working in an environment where no clear "company standards" are in place.
Complications arise when trying to use the internal "source code management" scheme as the release version identified with the final QA project, as well as having no clear identification of whether a release is a major or minor release, or a full revision, or simply an update. It seems there is little documentation on this subject available for clarification when performing an online search. However, it should be understood that a release version which is used to identify the final product will not change throughout the entire final release process, regardless of the number of defects and internal builds which are required to achieve an acceptable final product. This is not true of internal build numbers which will change with every new compilation of the code and may vary drastically by the end of the QA cycle from what was originally submitted.
Software development departments should recognize the need to have an established "release version" schema in place for "project control" (so project names do not need to be altered during the QA process), as well as the other factors mentioned above (upgrade vs. major revision, ease of identification by users, shorter names used in registry, control panel, and desktop icons, etc.). For companies which cannot see anything wrong with using build numbering schema as their release version, they will continue to experience complications and confusion when the first defect is corrected, resulting in a build version identified with the application which at that point now differs from the established "release version" the project was opened, named after, and identified with.
There is also a complication with release versioning which arises when automatic "application updaters" are incorporated into an applications code. When an application is designed with an "automatic updater" feature built in, it automatically connects with a server when it is first opened, and retrieves updates from the server. The version of the application is updated from the server as well, using an internal numbering scheme. This internal numbering scheme can include either points (e.g. 126.96.36.199) date and time (2005.10.03 1600) or some other schema.
When an internal numbering schema is used with applications which utilize an "automatic updater", the release version is often easy to determine, usually including only the first two or three numbers used in the internal scheme (i.e. version 7.5.3, using the example above). Updaters using dates as their schema are much more difficult to determine a final release version for however, as there is nothing in common with the original release version and subsequent updates which is evident once the first update is implemented (i.e. "2005.10.03 1600", which suddenly becomes "2006.1.04 0800" when the auto update kicks in). There is also the aspect that the various software tools used for packaging will not accept these "non-standard" formats in their version fields, which are required fields in the packaging software.
Although it does not address the aspect of a version number changing should a defect be found during final QA testing, requiring a new build to be delivered: one way to negotiate internal version numbers which are date related (possibly with an associated build number), is to convert them to a "related point version". So, in the given example, 2005.10.03 1600 would become simply version "05.10.03" with the next update in the above example being version "06.01.04". This format of "YY.DD.MM" using numeric characters at least satisfies the requirement most packaging software have for the format of the version to be in a standardized point version schema.
For ease of tracking release versions with applications which use an internal numbering scheme using dates, it is often much easier to use an external version number which is not related to the internal date scheme, such as version 1.0, 1.1, 1.2, etc. which are not affected adversely when the build number changes during final QA testing, for the purpose of project management and ease of identification of a particular release version.
they skipped version 4, saying that version 5 was the best aspects of 2 and 3 added together. not sure if this is notable enough to include in "Unusual versioning schemes" - Omegatron 15:35, May 12, 2005 (UTC)
I said "identical" for good reason
Even if you felt it needed compression, softening that was *not* acceptable. I'm happy to discuss the issue, but your "it's his MFTL" attitude isn't likely to get you very far. As noted in the CVS comment, it is *not* my favorite toy versioning scheme; I stole it from all the other people who use it -- I'm a systems analyst by profession; figuring out the best approach to a problem is what I get paid for.
That is the most featureful approach, while simultaneously being less complicated to understand for most people, and yet it wasn't mentioned at all.
So I added it.
Discuss before verting.
--Baylink 22:37, 11 Jun 2005 (UTC)
The numeric versioning bit is getting lengthy, and without apparent structure. Any ideas / suggestions on how to cure this? --Trevor Parker 23:39, 7 February 2006 (UTC)
- Dramatic simplification? That's a big block of text!
- User:Ojw/VersionSchemes has some notes, although it overlaps with naming schemes. Ojw 16:10, 29 April 2006 (UTC)
- There was a lot of text in that paragraph which didn't describe the scheme itself, but modifications to it, ways of interpreting it, political significance of numbers, etc. -- I've tried moving those to their own headings, to see it that makes it any more readable? Ojw 16:37, 29 April 2006 (UTC)
Someone should probably create a Version (disambiguation) page to link this page and at least the following others:
- External cephalic version - currently linked from the "See also" section of this page, which it shouldn't be.
- Version (eye)
I'm no Wikipedia expert so it's probably best if someone other than me does this. --188.8.131.52 16:32, 4 July 2006 (UTC)
Versioning in general
There are actually two things that are versioned in general:
- Some atomic entity (in CVS/SVN/CMS/... it is the file).
- A collection of atomic entities.
Hence, we should disinguish between the two. Also, for one purpose, a collection may be atomic (i.e. the marketing division @ Microsoft sees the entire operating system as an atomic whole, and thus 'versions' it as Windows XP 2000). Then for the purpose of some developers at Microsoft a small set of files comprices the socket library (which then also gets its version). Finally, Mr. BigProgrammer (lots of pizza), is *the* editor of sock.c. This file is also individually versioned in some versioning system.
My point being: It is not possible to talk generally about versioning in other ways than just specify what is versioned, and the scheme of the numbering system: My car is in its next version after it has had a maintenance service; it would be nice if that version was a higher number than the previous one so that it is easy to talk about it and track it. Since it it my car, I'll adopt a numbering scheme, I think ;-)
Versioned things are:
- A description of things that comprices an atom in our version database. Being an atom, all actions performed on it should be atomic (with regards to the versioning database).
- A set of actions to take to make the next version of the atom.
For version control systems, the description of the atom is the file (and the folder for Subversion). The actions to take are well defined for files and folders by the tool in use, such as 'check-in', 'check-out', 'commit' etc.
What I'm missing from the versioning systems is an easy way to define a collection of atoms (to create a new kind of atom) and a way to treat such a collection exactly the same way as we treat files.
Hawkis 15:44, 9 August 2006 (UTC)
version vs revision
Version is something that is produced for 'others' to see. Revision is something that is produced for 'originators' to see.
Both are as a point of completion.
When something becomes so important as to lose its ambiguity as a requirement between the 'originators' and the 'others', it attains the value of a new version. It is made available to those defined as 'other'.
These two deterministic rules simplify the question of difference.
'Originators' who are confused about what is being done for 'others' will result in new versions/revisions with ambiguous intent or modify the the system to match the ambiguity. It would appear that certain systems, because they exist, exacerbate this.
Ubuntu-style version names?
It would be good if the article mentioned more exotic schemes e.g. like the different Ubuntu linux versions (xubuntu, kubuntu, edubuntu) Interestingly there are also human readable along numeric version: "Dapper Drake", "Edgy Eft" etc.
versioning system != decimal system?
I've noticed that sometimes versions use, for instance, 1.10 as the version after 1.9, which doesn't follow the standard decimal system (being 1.10 == 1.1). Is this considered acceptable when numbering releases? Is the "." (period) just a separator, and not an actual decimal? Qhiiyr 14:22, 11 July 2007 (UTC)
- Good question, and one that I don't think has a convention. (just like this entire Software Versioning topic!) ;) It also leads to verbal ambiguities, too - i.e., what is version "five dot one"? Is it 5.1? 5.01? And as you asked, is 5.1 == 5.10?
- These ambiguity is why I've advocated in the products I manage that the second and third integers in a version (minor and patch in my products) always be two digits. If the number is < 10, you pad it with a prefixing zero (e.g. 1.05, 1.05.02). If the number grows beyond 2 digits (not impossible, but has never happened, we would have 1.99 -> 1.100. Perhaps still potentially confusing, but as I said, this has never happened to me in practice. ChrisRing 19:56, 13 July 2007 (UTC)
- Okay, cool. Thanks for your help! Qhiiyr 02:29, 15 July 2007 (UTC)
- This is a confusing aspect to version numbers and I was just going to say that there should be some text in the article about it (and other ways versions can be confusing). A few years ago, there was some extremely heated debate on the Rage3D boads about the ATI Catalyst drivers. There was confusion about the version and despite some people’s best efforts (my own included) to explain that a version like 184.108.40.206 is not a decimal number and that the dots are not decimal points, there were people who vehemently fought that it was inconsistent and wrong. I think the debate was significant enough to merit a mention in the article, especially since it got so big and went so long. I’ll see if I can find the thread. Synetech (talk) 22:45, 23 August 2008 (UTC)
- I use a different system to resolve this (in my own software): Ten minors are worth one major and ten revisions are worth one minor. (So, a major or minor version after 2.9 would be called 3.0 either way) --zzo38(✉) 18:08, 11 July 2010 (UTC)
A number I see commonly recurring in all manner of versioning type stuff... Could someone explain the significance for me? Examples: Forceware 169.x or Dwarf Fortress v0.27.169.33a --220.127.116.11 (talk) 07:20, 26 November 2008 (UTC)
Do you know an application that use this schema?
It can be used in the third position:
- 0 for alpha status
- 1 for beta status
- 2 for release candidate
- 3 for public release
- 18.104.22.168 instead of 1.2-a
- 22.214.171.124 instead of 1.2-b2 (beta with some bug fixes)
- 126.96.36.199 instead of 1.2-rc
- 188.8.131.52 instead of 1.2-r (commercial distribution)
- 184.108.40.206 instead of 1.2-r5 (commercial distribution with many bug fixes)
Microsoft's build number is actually an encoded date?
The source for this information only talks about MS Office. This is definitely not true for Windows, because the first two numbers would be for the month after the project started and the last two for teh day of thois month. Windows 98 hhast the build number 1998, but it was defintely not released on the 98. day of a month, Win 98SE ist 2222, but it was released much more then 3 months after Win 98 and also on the 5th day of the month it was released (release date 05/05/99). Also the NT-series doesn't use encoded dates the was that it is mentined in the source, i.E. because NT 4.0 has build 1381 and Vista has build 6000. --MrBurns (talk) 09:40, 9 April 2009 (UTC)
- By "encoded" the writer means the actual date is changed into a secret code, not simply that it is in the software code. Microsoft's development is a carefully guarded secret, they do not want other companies or the public to know their progress (or lack of progress) on their projects. Not to mention they use a different set of numbers that resemble versioning numbers, for marketing purposes. For instance Windows 2000 did not develop from 98 or 95, it was developed from NT 4.0 server, but MS wanted customers to "upgrade" in the sequence presented. There are many instances where a number or numbers was presented to the public deceptively, pretending to be related to internal development. People who are only casually familiar with development process might mistake the new upgrade or update for being much more advanced than it actually may be. I don't know if presenting such examples is encyclopedic because it reflects badly on the companies that have done this. Tumacama (talk) 19:26, 17 November 2009 (UTC)
I'm curious about the versioning method mozilla is using with Firefox. Its current release is 3.0.10 It came after 3.0.9 shouldnt the next release after 3.0.9 be 3.1 or 3.0.9x? 220.127.116.11 (talk) 18:07, 7 May 2009 (UTC)
- This has been more clear since because Firefox develops different versions simultaneously. It is working on a stable 3.5.x branch, and unstable 3.6.x branch, and still developing 3.0.x. Because Firefox is free and doesn't (directly) profit from upgrades, they can simultaneously please "customers" who are happy with old versions 3.0.x, but still need security updates. Open Source projects can and need to use versioning numbers to reflect actual project advancements and changes from a strictly software engineering POV. Commercial projects may have customer relations and even internal company psychology and politics as factors influencing the versioning number process. The two different types should probably get different treatments in this article. Tumacama (talk) 19:39, 17 November 2009 (UTC)
The truth about interpreting Version Numbers
Here is the proper interpretation of a piece of software labelled as v0.01RC1a2:
|V0.||I have inadequacy issues|
|V0.01||Also I'm afraid my mother will yell at me.|
|V0.01RC1||From that one time last summer when my girlfriend decided to have sex with me. Just a release candidate though, not an actual release. (She left me shortly thereafter...)|
|V0.01RC1a||My brother Joey started helping me, and did a major revision. But it's MY project.|
|V0.01RC1a2||That bit I did last weekend; mostly airbrushing some sprites.|
|V8.2||Had to kill that nagging feeling that there might be a sense of scale/order to it. (Also got sick of people laughing at me.)|
How to version your Python projects
Is the "How to version your Python projects" link really useful? The linked document is empty.
New Versioning Method
I sit here in this company with a setup guide document we're developing for the software this company made, upgrades, and supports. The guys in the Software department who have written this document thought it proper to name all versions 1.0 (seriously). This is the third revision of 1.0 I've done, and I expect I'll get version 1.0 in an email shortly.
1.0 was absolutely full of mistakes, 1.0 wasn't too bad, 1.0 I got as a PDF and found more stuff wrong with than the paper 1.0 and 1.0 versions.
I am dead serious about this. We've mentioned this to them many times but their response is that since we haven't actually released a version yet, it's still 1.0
- WTF? Guess it didn't occur to them that if release==1.0 then pre-release builds can be 0.1, 0.2, 0.3, 0.4, and so forth? Would their poor little heads explode if they thought about version numbers <1.0? Hilarious. On their way to winning in the marketplace because of their superior thinking skills?! Thanks for sharing the laugh. — ¾-10 22:35, 4 October 2010 (UTC)
GloboLinux and octal versioning
uses a octal version number sinse version 7 suced 10 and for 17 susced 20 onli numbering the se number (if I remember the actual version is 23) — Preceding unsigned comment added by 18.104.22.168 (talk) 20:37, 30 May 2011 (UTC)
Calendar based version numbering scheme
Increment the major number each decade, the minor number each year, the maintenance number monthly, and the build number weekly. So for example, a Linux kernel release on May 1st 2011 would be version 22.214.171.124. —Preceding unsigned comment added by 126.96.36.199 (talk) 03:50, 24 May 2011 (UTC)
Time to edit this talk page?
There seems to be a bunch of content on this talk page that violates WP:TPG, making it quite messy:
- Some anecdotes that, while funny, don't discuss the article:
- The truth about interpreting Version Numbers
- New versioning method
- Topics that discuss software versioning itself, rather than the article:
- Versioning in general
- version vs revision
- versioning system != decimal system?
- Do you know an application that use this schema?
- Microsoft's build number is actually an encoded date?
- GloboLinux and octal versioning
- Calendar based version numbering scheme
- An unsigned ten paragraph essay above the table of contents that seems to be one person's personal reflections on software versioning and, again, doesn't discuss the article itself.
I was going to delete all this stuff, but the guidance at WP:TPG made me a bit skittish about deleting, so I'd like to seek some concensus before doing so. — Preceding unsigned comment added by SixSix (talk • contribs) 15:24, 5 August 2011 (UTC)
- Why not just move the offending material to an archive page, as WP:TPG recommends? -- Schapel (talk) 20:04, 5 August 2011 (UTC)
- Whatever is decided, I think it needs a cleanup, too. Bujiraso (talk) 15:42, 11 June 2013 (UTC)
This concept has not been described.
Keeping up with competitors
It would be interesting to have some history
If anybody can track down some history of versioning schemes, it would be interesting to know. For example, back in the good old days, "everybody knew" that version numbers were just a series of integers separated by periods. (Not decimal points!) I know from personal experience that this convention pre-dates the mid-1970's, but where did it come from? As more people came in to the computing field without significant contact with their predecessors, there was an explosion of interpretations of the meaning of version numbers. (Such as the idea that they are floating point numbers, adding letters, leading zeros, etc.)
I don't have any cites for any of this, but I'm thinking the origin of version numbers is probably somewhere in the late 50's / early 60's, like so much other fundamental computer technology. 188.8.131.52 (talk) 19:47, 14 April 2014 (UTC)
"If changes are made between, say, 1.3rc4 (a release candidate) and the production release of 1.3, then that release, which asserts that it has had a production-grade level of testing in the real world, in fact contains changes which have not necessarily been tested in the real world at all.[clarification needed]"
This doesn't make sense at all. Doesn't seem to be a complete sentece.
- Why are there no dots in the version number?
- I use a very simple version numbering scheme. The first version of less was version 1. The next was version 2. And so on. There are no "major" and "minor" releases, so there are no dots in the version number. So version 381 is the three hundred and eighty-first version of less. It's just 381, not 3.81 or 3.8.1.