Incrementing version number/build number help.

[AlTech]

So i am a little confused and lost on how to update my version number and build number of apps.

 

Mostly my issue is how to increment a build number.

 

1) By what amount do i increase it each time?

2) What factors would justify increasing it?

3) When do build numbers with decimals come into play?

 

 

And which way of version numbering sounds better:

A) [Program name] [Current Year] Update [update number within that year]

B) [Program name] [Main version].[Minor version].[build number]

C) [Program name] [Main version].[Minor version] Build [build number]

 

Thanks

[Dobbsjr]

 

I have asked a similar question before: http://linustechtips.com/main/topic/405703-how-does-software-versioning-work/

 

A quote from @alpenwasser 

 

 

 

As has been said, there isn't really any set standard and you can basically do what you

want. There are also rather esoteric version numbering schemes out there. For example,

Donald Knuth uses pi as his versioning system for TeX, adding ever more decimal digits

to each version. A neat gimmick, but not necessarily very useful if you want to actually

extract information from the versioning number, at least as far as I can tell.

There is the concept of semantic versioning though, developed by one of the co-founders

of github (though I'm pretty sure the general concepts behind it have been around longer,

I reckon he's just the one who finally put it in a systematic coherent form and gave it

a name), which is laid out here: http://semver.org/

The fundamentals are:

Quote

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards-compatible manner, and
• PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

 

You can read more about its finer points on its website. As said though, even this

is not a god-given standard, it is something which has had a lot of thought put into

it, but that doesn't oblige you to follow it. 

[manikyath]

theres quite a few different standards (and people who use to refuse standards) in the world of version numbering.

 

my current favourite is the versioning FTB (feed the beast - a minecraft modpack and map development team) uses, based on a 3 number system.

 

first digit is the major versions;

0 - alpha/beta stages

1 - initial release

*  - major changes

 

second digit:

sub versions, indicate changes that arent world breaking, but could otherwise indicate problems with using old worlds like added or removed mods.

third digit:

small fixes like config tweaks or mod updates that do not add or remove major features, and are only intended fix bugs.

 

while this is a very specific versioning system to their work, its easily adaptable to whatever you're doing.

 

the wikipedia artcile on version numbering may be helpful as well https://en.wikipedia.org/wiki/Software_versioning

 

i prefer example B you gave out the 3, as i dont really like the "annual release" model because it doesnt indicate advancements made in code, rather it lists advancements made in time.

(example: i can tell you ubuntu 12.04 is two years older than 14.04, but i can tell you there were huge changes between manjaro linux 6.4.0 and 8.6.3)

[DevBlox]

I usually go by these rules. 3 digits [1].[2].[3]. Increments when:

3) A bug fix or even a bigger fix happens, no functionality changes

2) Functionality added

1) Breaking changes, no longer backwards compatible

When a number is incremented all numbers to the right of it are reset to 0.

 

I guess this wouldn't work with games or something. I use this mainly for libraries or applications with slow release cycle. For continuous deployment applications that are updated extremely often I just use the build number as the single digit and that's it, mostly because you can't quite capture breaking changes good enough, these applications tend to grow out of this build number system quite fast.

[Brenz]

Another vote for Semver