How does software versioning work?

[Dobbsjr]

On wikipedia it says version numbers work somewhat like this: major.minor[.build[.revision]], but what counts as a revision? And when is it appropriate to say a certain software is alpha or beta?

[mantylt]

It's common consensus, but all depends on company developing software. They decide format of version string and when project reaches alpha, beta stages. Even in company I work, we use multiple formats for different projects. 

 

@Dobbsjr follow your own topics to get notifications

[DavidTheWin]

There's no set standard for versioning which is fine because not all software can be versioned in the same way. A common one like you said is major.minor.possibly another minor.revision. The major version goes up when you have a lot of changes or say a few very large changes, minor goes up when it's a few small changes and revision is just the revision of your code repo. The second minor revision is for tiny changes like hotfixes. The revision of your code repo is very important because by looking through the revision history you know exactly what code you deployed.

This style is very common because it works for a lot of software projects. However it differs between companies and teams within those companies. For example, there are some teams within my organisation that seem to just use 1.major (stupid IMO) and one of the applications my team develops is year.month.revision, e.g. 15.6.49607 is the June 2015 release at code revision 49607.

 

Alpha and beta are very different and well defined terms. Alpha testing is carried out by the testers (this could be another role of the developer) within the company in a controlled environment to test for functionality and any low hanging bugs. It's not open to anyone outside the organisation. Beta testing on the other hand is performed by the end users of the product. This might be an open beta for a game where anyone can try it out, or it might be a group of developers at the customer trying it out. At this stage it will undergo testing in something that is supposed to approximate a live environment although you can rarely get close to that, think about how many games have server issues on launch because you can't stress test your servers with that many people in a beta.

[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:

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.

[mikat]

On wikipedia it says version numbers work somewhat like this: major.minor[.build[.revision]], but what counts as a revision and what counts as a revision? And when is it appropriate to say a certain software is alpha or beta?

the software maker decides?

[SSL]

Semantic Versioning

 

This is the scheme I prefer. Frequently, software versions are meaningless and thus useless because the developers follow no guidelines, or if they do they aren't documented.

[burnttoastnice]

I think it differs with software.

Personally for me, while developing a program I made called LightningLaunch, the Alpha stage was when there was the most bugs. After the majority of those were sorted out, I then moved into the Beta stage, when there was much less bugs, and started allowing people to use the program.

As for the versioning, a whole number would usually mean lots of new features implemented, and decimal numbers would mean user-suggested features and assorted bug fixes and enhancements.

 

I've attached below a screenshot of my program's version history, which says the version and what features were changed/added along with it.

[Dobbsjr]

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Thanks everyone!