Talk:Software versioning

From Wikipedia, the free encyclopedia

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.

Contents

[edit] 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)

[edit] 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)

[edit] 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)

[edit] Disambiguation

Someone should probably create a Version (disambiguation) page to link this page and at least the following others:

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)

[edit] 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)

[edit] 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.

[edit] 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.

[edit] 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)