Talk:Software versioning/Archive 1

Archive 1

Noise from the past

Extended content

Untitled ramblings

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. 7.5.3.2) 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. — Preceding unsigned comment added by [[User:{{{1}}}|{{{1}}}]] ([[User talk:{{{1}}}#top|talk]] • [[Special:Contributions/{{{1}}}|contribs]])

The above diatribe seems to have been contributed by the original author of this talk page. I could not identify them from the history. It goes on about that author's personal views on versioning and says nothing about the article itself and should be deleted soon. JwD (talk) 00:57, 3 March 2018 (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)

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 19:50, 3 March 2018 (UTC)

winamp

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 moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 19:52, 3 March 2018 (UTC)

169?

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 --173.20.106.196 (talk) 07:20, 26 November 2008 (UTC)

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 19:56, 3 March 2018 (UTC)

Numeric Versioning

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)

I moved this because it's really old and doesn't seem relevant to current discussions, and it seems to have been addressed long ago. JwD (talk) 20:14, 3 March 2018 (UTC)

Disambiguation

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. --128.112.85.122 16:32, 4 July 2006 (UTC)

I moved this because it's really old and doesn't seem relevant to current discussions, and it seems to have been addressed long ago. JwD (talk) 20:17, 3 March 2018 (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. — Preceding unsigned comment added by

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 20:23, 3 March 2018 (UTC)

Skype

What's the third number in Skype's version numbering system? For some reason it's always 0... They use a major.minor.0.build system. Guy0307 (talk) 02:24, 5 October 2008 (UTC)

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 20:30, 3 March 2018 (UTC)

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. — Preceding unsigned comment added by

I moved this because it's really old and doesn't seem relevant to current discussions.

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 1.2.3.4 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)

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 20:41, 3 March 2018 (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

For instance:

• 1.2.0.1 instead of 1.2-a
• 1.2.1.2 instead of 1.2-b2 (beta with some bug fixes)
• 1.2.2.3 instead of 1.2-rc
• 1.2.3.0 instead of 1.2-r (commercial distribution)
• 1.2.3.5 instead of 1.2-r5 (commercial distribution with many bug fixes)

Caracho (talk) 18:19, 31 March 2009 (UTC)Caracho; 18:14, 31 March 2009 (UTC)Caracho, 2009-03-31

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 20:47, 3 March 2018 (UTC)

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 moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 20:56, 3 March 2018 (UTC)

Firefox 3.0.x?

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? 213.7.132.106 (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)

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 21:01, 3 March 2018 (UTC)

The truth about interpreting Version Numbers

Here is the proper interpretation of a piece of software labelled as v0.01RC1a2:

Section	Interpretation
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.)

Fun and games :) AngleWyrm (talk) 20:37, 10 March 2010 (UTC)

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 21:22, 3 March 2018 (UTC)

How to version your Python projects

Is the "How to version your Python projects" link really useful? The linked document is empty.

B.orc (talk) 14:04, 30 August 2010 (UTC)

I moved this because it's really old and doesn't seem relevant to current discussions, and it seems to have been addressed in the article. JwD (talk) 21:26, 3 March 2018 (UTC)

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

lmao. —Preceding unsigned comment added by Deadly-bagel (talk • contribs) 12:59, 30 September 2010 (UTC)

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)

I moved this because it's really old and doesn't seem relevant to current discussions, and I really don't see how it can help us improve the article. JwD (talk) 21:30, 3 March 2018 (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 190.20.30.114 (talk) 20:37, 30 May 2011 (UTC)

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 21:36, 3 March 2018 (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 3.1.5.1. —Preceding unsigned comment added by 173.19.239.121 (talk) 03:50, 24 May 2011 (UTC)

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 21:40, 3 March 2018 (UTC)

Parallel versions

This concept has not been described. — Preceding unsigned comment added by

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 21:44, 3 March 2018 (UTC)

Keeping up with competitors

this section should also include info about chrome Norill (talk) 12:01, 13 March 2014 (UTC)

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 21:47, 3 March 2018 (UTC)

less

CLI text file viewer less(1) uses just an incrementing integers. From their FAQ:

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.

I am not sure where this information fits, so if somebody else with a better grasp on this article could incorporate it, world would be much nicer (IMHO). Ceplm (talk) 09:33, 18 August 2015 (UTC)

I don't think the article should focus on individual product team's version schemes, but the article should cover the commonest schemes, include single, double, triple and quadruple, beyond that, if you know of a documented scheme for a particular product, add a link to it in the External Links section. JwD (talk) 00:37, 3 March 2018 (UTC)

I moved this because it's really old and doesn't seem relevant to current discussions. JwD (talk) 22:04, 3 March 2018 (UTC)

Archive 1