vendredi 8 février 2013

Naming convention for software version

To identify a source code version is a good way to save time during development, test, and deployment phases.
Without it, it is difficult to communicate with all the collaborators, developers, software testers, and final users.

Choosing a naming convention for source code version makes project status easier to control.

Pour une version française de l'article, cliquez sur ce lien :

Lay the versioning service aside

It seems to be a good thing to use the revision number of the versioning service, like revisions in Subversion, but it is a bad idea. If you wanna change the versioning service, from Subversion to Git, Mercurial, or else, we will loose these revision numbers.

My simple naming convention

The convention I describe below is not the most relevant, the best, or the easiest to maintain. It is based to my personal experience, it works properly for almost cases and it can be a good start to create yours.

Level-based incremental naming convention

To determine the version of a software source code, I use the four-valued M.F.R[.T] format. It is possible to use only three values but the logic has to be more complicated if you wanna identify easily test versions and release versions.

M is the Major version number. This level has a technical and a marketing dimension, because it is more attractive to communicate about a major update.
Incrementing this level is the sign of big changes of software features, and usually (but not necessary) a non-compatibility with previous versions.

F (as Features) is for minor version. At this level, it's more about new features, or feature updates. These updates have to keep the backward compatibility with previous minor versions of the same major version.

R is the Revision number. It is the technical level of bug fixes, and optimizations. All the revisions of the same minor version must be compatible each other.

T is a number for Tag. This level is reserved to internal usage, and helps the development team to identify the testable versions. That means that release versions will never have a name with this level of precision.


  1. Day 0. The project is just starting and everything is to be done. The version of the software source code is theoretically, but this version is useless, because nothing exists to be tagged in a version.
    It is defined a list of features to be developed and integrated to create the 1.0.0 version that will be released to final users (and not
  2. The dev team starts developing the modules, and when a first version is testable, a version is made.
    It's the version.
    This version proves that some source code or assets have been produced since the last version ( Developers run technical tests (like unit tests). Then a functional test has to be run.
  3. This version is tested, and validate (1), or not (2), the candidate version.
    1. If the version is validated, the new version is created, with a new name. The tag is removed because the new version can be released.
      1. If some features have been added or modified, the minor version number is incremented and the revision number is set to zero.
        This will be the 0.1.0 version.
      2. If this is a technical update, the revision number is incremented.
        This will be the 0.0.1 version.
      1. If the version is not validated, developers have to fix bugs and integrate suggestions. Then a new version is created, and tested.
        This is the version.
    2. When all the awaited features are developed and tested, the major version number is incremented, the minor and revision numbers are set to zero.
      The 1.0.0 version est created.
    3. The dev team follows the same steps again, and again.

    The SubVersion case

    How to integrate this naming convention into SubVersion efficiently ? It's all about branches and tags.

    Tag in SubVersion is a good way to set versions, because a given version doesn't have to be modified. Thanks to tags, it is easy to create a sort of snapshot of the source code. It is what we want when we create a version, that has to set the features and the technical qualities of the source code.

    Branches are used for two reasons.

    The first way to use branches is to maintain several versions of the source code in parallel.
    For example, we can create the v1.x branch and the v2.x branch, or more precisely a v1.3.x branch, etc. It is useful when you sell licenses of your software. All the clients do not have the last version, but they can report bugs that you have to fix.
    In that way, we can fix bugs and optimize each version independently.

    The second way is to create a working version in order not to disturb the main source code (that is in the trunk). This way to use branches allow you to save your code.
    I personally think that versioning services is not a good way to protect a developer from hardware failure or mishandling. Some other services exists to do that. However, I admit that it is quite handy to save your work in a personal branch even if the code is not stable, because using too many services is evil.

    The GIT case

    (next update)

    Aucun commentaire:

    Enregistrer un commentaire