AluminiumTech's Version Numbering Guidelines - Version Numbering Guide v1

[AlTech]

Hello everybody ,

 

I've seen a influx of users starting to make their own programming projects and I've decided I want to help people with version numbering for projects.

 

This can apply to websites, programs, apps. or games.

 

Enjoy !

 

 

So, version numbering is a big deal. Developers and customers (the users of applications, websites, programs or games) rely on it to understand how significant an update is.

 

From the consumer side of things, customers can base a decision as to whether or not to update purely going off of what the version number is called.

 

Traditionally, there have been a few ways people use version numbering. I've nicknamed them so that they're easier to remember.

 

The Corporate/Marketing Version

This is essentially when an app increases the major version so that it is a more marketable update and so that consumers can more easily differentiate between updates. This is used by Google's Chrome, Microsoft Edge, Microsoft Windows, Mozilla Firefox and is generally used by large corporations.

 

This is not very user-friendly as updates are hard to identify if they are significant or not.  One update might appear significant but might be quite meaningless such as jumping from Chrome 55 to Chrome 56.

 

This is generally used by those who do not believe in free (as in speech) and OSS software.

 

The OSS Version

This version numbering scheme is quite straightforward and is generally what most will want to use.

 

It's typically used by Open Source Software (although there are some exceptions).

 

It constitutes naming a version in a fashion which is easily identifiable even if it is not easy to market to people.

 

The scheme typically goes along the lines of [Major].[Minor].[Build/Bug fix].[Revision] .

 

Major represents when there is a huge change to something OR what development stage the program is in.

Programs, games or apps in Early Alpha, Pre-alpha or Alpha can use 0.x.x.x as their numbering scheme.

Those which are in Beta, Pre-release or release can typically start with their first release in the stage as 1.x.x.x .

When to increment the Major number: Whenever there is a major fundamental way the program works or whenever there are incompatible changes which won't work on earlier versions.

 

Minor represents when there are changes which don't break compatibility and are relatively small. 

When to increment the Minor number: Whenever there is a small change, be it an addition or tweak, to the program.

 

Build/Bug Fix represents when a new build is released which fixed some issues or provides really minor tweaks to the program.

When to increment: Whenever you fix a bug or need to make a tiny change to your program.

 

Revision represents when an existing version of your app needs an update to fix it. This is usually the case if is a critical bug which causes the app not to work or not to work as intended.

When to increment: If you had an app of version 1.5.0.0 but discovered it broke half of the features, it would be wise to release 1.5.0.1 which fixes the version.

 

The Gaming Version

This is quite similar to the OSS version except it's a little bit more alphabetical rather than numerical.

 

This can include using "a" for alpha or "b' for beta.

 

They can also include using names to represent big updates such as "Adventures in Finance and Felony update" rather than v1.67

 

Semantic Versioning

Semantic versioning is an idea similar to the OSS version except the version numbering contains Major.Minor.Patch and follows a specific set of rules.

 

The set of rules on what is and what is not allowed is to ensure that there is even easier to identify different versions and tell them apart,

 

Check out the latest version of semantic versioning here -> http://semver.org/spec/v2.0.0.html

 

What to use?

I'd recommend using the OSS Version OR Semantic versioning.

 

They're both good version numbering methods which many open source programs and also closed source programs seem to be adopting.

 

If you have any questions then please ask me .

Edited February 25, 2017 by AluminiumTech
added semantic versioning

[RGProductions]

Now all we need is a CPU naming guide

[2FA]

Just a suggestion in regards to the OSS major number. I see a lot of people use 'a' for alpha versions and 'b' for beta versions, especially in the game modding community. I know it's not really an official way but is still pretty common.

[AlTech]

15 minutes ago, DeadEyePsycho said:

Just a suggestion in regards to the OSS major number. I see a lot of people use 'a' for alpha versions and 'b' for beta versions, especially in the game modding community. I know it's not really an official way but is still pretty common.

I'll add that in in a note in the post . ty.

[squirrl]

There is no BEST way of versioning, but you also failed to mention anything about semantic versioning:

http://semver.org/

This is similar to your OSS version without the revision (which is pretty much the same as patch) being picked up by many projects which can be used as dependencies in order to for their users to know if they should be able to update a dependency without breaking anything. 

 

Quote

If you had an app of version 1.5.0.0 but discovered it broke half of the features

You have really bad QA and should rethink your testing strategy.

[AlTech]

1 minute ago, squirrl said:

There is no BEST way of versioning, but you also failed to mention anything about semantic versioning:

http://semver.org/

I will add this in!

1 minute ago, squirrl said:

This is similar to your OSS version without the revision (which is pretty much the same as patch) being picked up by many projects which can be used as dependencies in order to for their users to know if they should be able to update a dependency without breaking anything. 

Same with this!

1 minute ago, squirrl said:

You have really bad QA and should rethink your testing strategy.

That was just a made up example lol .

[Mira Yurizaki]

Eh, it bothers me that this post shuffles versioning into its own categories when in fact, most software development companies use the so-called OSS scheme (which I never even heard that was a thing). For example, the latest customer-released version of the NT kernel is 10.0.14393.729, which follows the [Major].[Minor].[Build number].[Whatever else this is used for] scheme. Though Microsoft short hands this to 1607 for the year and month it was released.

 

There are plenty of reasons and ways to version something and each schema is used for whatever reason the development team wants to use.

 

In my case, since I maintain a user script, I follow a [Major].[Minor].[Update][Revision] scheme.

• Major versions were any huge sweeping changes to the code base. It would require a regression test to make sure nothing broke.
• Minor versions were any major updates to an aspect of the script. Like if I made a broad change to a section of features. The level of testing required was the section of features this affected.
• Update versions were anything small. Like adding a checkbox to enable a tiny feature or fixing a minor bug. The level of testing required was just that change.
• Revisions were time dependent, like if I had to fix a minor bug that was caught within a week or so after release.

The real take away of versioning is that you have an actual scheme and some semblance of a justification for it, rather than incrementing a number just because. If you want to use build numbers as your versioning system, that's fine. If you want a ten-section versioning system, that's fine too. But have a reason and a standard for it.