Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The game development package Unity uses the following version numbering scheme:

{major}.{minor}.{patch}{type}{number}

With the following known types:

  • a = alpha
  • b = beta
  • f = final

Some examples:

  • 1.2.3a27
  • 1.2.3b4
  • 1.2.3f2

Is this a standard formatting for version numbers?

share|improve this question
    
I do not see how this question is opinion based... –  Lea Hayes Jun 16 at 13:48
1  
The closest thing to a standard is the specification for semantic versioning. Unity's versioning scheme is a slight variation of it. –  Doval Jun 16 at 14:17

2 Answers 2

up vote 2 down vote accepted

It appears to be fairly common, yes. Have a look at the Wikipedia article on software versioning.

Quote below is from that page:


Designating development stage

Some schemes use a zero in the first sequence to designate alpha or beta status for releases that are not stable enough for general or practical deployment and are intended for testing or internal use only.

It can be used in the third position:

0 for alpha (status)
1 for beta (status)
2 for release candidate
3 for (final) release

For instance:

1.2.0.1 instead of 1.2-a1
1.2.1.2 instead of 1.2-b2 (beta with some bug fixes)
1.2.2.3 instead of 1.2-rc3 (release candidate)
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)
share|improve this answer

Not as such; There is not one standard versioning scheme. As such, each project tends to choose a versioning scheme that fits their development/release model (and this is perfectly fine, as long as the versioning scheme is known, consistent and respected by developers).

Here are some version examples I've used over the years:

  • Linux/OSS - style version (start from 0.1 and increment with each small feature; when stable, increment to 1.0)

  • Windows applications - style version (start from 1.0[.0] with the last numbers representing major version, minor version and build number)

  • Linux-kernel - style convention (start from 0.1.0, increment version with each stable feature; increment by two for each internal revision, keeping odd build numbers as internal builds, and defining the version using the next odd build number with each public release)

  • custom (I have various examples on this). The last time I developed a library for a customer, the library was termed 1.0RC - release candidate. With each revision to the library the "RC number" was increased - so I had 1.0RC1, 1.0RC2 and so on.

    The library would have become 1.0 when the first customer would have begun using it, then each revision on top of that would have been 1.1RC, 1.1RC2 and so on. I left the project when the library was at 1.0RC3 though.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.