Version numbering

We’ve been setting up a continuous integration environment at my daytime work, and looking at automatic versioning of our projects I’ve been wondering the web for information about versioning.

Here’s what I’ve come up with:


Whatever meaning you give to the different parts in a version number, it is arbitrary. So pick one and stick to it. However, there are some “best practices” where most people seem to agree about:

  1. Make a difference between label in source control and version of binary. The label in the source control adds meaning about the development stage your project is in.
  2. Don’t let the marketing guys get in control of your version numbering scheme. Make difference between the version of a binary and the “marketing version”.
  3. A version number of tree parts should suffice.
  4. Version numbers mostly allow differentiation between releases that break compatibility and those who don’t.

And the winner is…

We use a scheme based on the apache definition.

Version numbering of binaries:


  • major: Any change can be made. Available functionality can be removed and new functionality can be added.
  • minor: All available functionality must remain available and can not be changed. New functionality can be added.
  • bugfix: Only implementations of functions and methods can change. There will be no added functionality (no added methods, functions or parameters) or changed semantics (of funcions, methods or parameters)
  • build: We use the buildnumber to differentiate builds of a same {major.minor.bugfix} combination. When we start development, we decide on the kind of development we do (adding features (breaking/non-breaking) or bugfixing) and decide on the next versionnumber. From then on, the library gets this versionnumber. It’s as if we are saying: “we are working toward version x.y.z”. Of course, we don’t get there immediately and to differentiate between these “working toward” versions, we use the buildnumber.

Labeling in source code control:


  • major: see “Version numbering of binaries”
  • minor: see “Version numbering of binaries”
  • bugfix: see “Version numbering of binaries”
  • build: see “Version numbering of binaries”
  • state: in which state can be
    • “DEV”: We are still developing the functionality, and make no guarantees as to what is incorporated and what not. Testing by users doesn’t really make sense. There can (read “will”) be bugs.
    • “BETA”: Most funcionality is incorporated and testing by users can be started. There can (read “most probably will”) still be bugs.
    • “RC”: All functionality has been added. We now start stabilizing/bugfixing.

Questions remaining

  1. When is backward compatibility broken? This probably looks like a stupid question, but imagine: A DLL named “SomeFunctionality.dll” uses some other DLL’s, named “Other.dll” and “MoreOther.dll”. But then this “SomeFunctionality.dll” is changed and doesn’t use “Other.dll” anymore, but uses “Another.dll”. However, the interface of “SomeFunctionality.dll” didn’t change. Is backward compatibility broken or not?
  2. What about customer related changes to old software which breaks backward compatibility? Say for example you have version at a customer site. Meanwhile version 2.x.y.z has allready been released. Let’s say even version allready exists. Now the customer with version wants some new feature which breaks backward compatibility. However, major versions 2 and 3 are allready taken. What major version do you use?

I try to provide some answers to these questions in this follow-up post


One thought on “Version numbering

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s