Software versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software. [read more at]

  •  apache_maven

    We are currently asking ourselves at INNOVEO, if we need to keep a version of integration versions.
    Integration versions main objective is to be integrated with other modules to make and test an
    application or a framework. This question is quickly becoming essential when working with several
    modules, where you will have to to rely on intermediate, non finalized versions of modules.

    Since we are also following  the continuous integration paradigm for all our modules, Thanks to
    Apache MAVEN, these integration versions are produced by a continuous integration server
    (Team City from JetBrain), very frequently.

    So, how can you deal with these, possibly numerous, integration versions? The response is coming
    from this extract from IVY documentation

    There are basically two ways to deal with them,

    Use a naming convention
    The idea is pretty simple, each time you publish a new integration of your module you give the same
    name to the version (in maven world this is for example 1.0-SNAPSHOT). The dependency manager
    should then be aware that this version is special because it changes over time, so that it does not
    trust its local cache if it already has the version, but check the date of the version on the repository
    and see if it has changed.

    Create automatically a new version for each
    in this case you use either a build number or a timestamp to publish each new integration version
    with a new version name. Then you can use one of the numerous ways in Ivy to express a version
    constraint. Usually selecting the very latest one (using 'latest.integration' as version constraint) is

    But usually we recommend to use the second one, because using a new version each time you publish
    a new version better fits the version identity paradigm, and can make all your builds reproducible,
    even integration one. And this is interesting because it enables, with some work in your build system,
    to introduce a mechanism to promote an integration build to a more stable status, like a milestone
    or a release.

    The example given is very interesting...

    Imagine you have a customer which comes on a Monday morning and asks your latest version of your
    software, for testing or demonstration purpose. Obviously he needs it for the afternoon :-) Now if
    you have a continuous integration process and a good tracking of your changes and your artifacts, it
    may occur that you are actually able to fulfill his request without needing the use of a dolorean to
    give you some more time :-) But it may occur also that your latest version stable enough to be used
    for the purpose of the customer was actually built a few days ago, because the very latest just break
    a feature or introduce a new one you don't want to deliver. In this case, you can deliver this 'stable'
    integration build if you want, but be sure that a few days, or weeks, or even months later, the
    customer will ask for a bug fix on this demo only version. Why? Because it's a customer, and we
    all know how they are :-)

    So, with a build promotion feature of any build in your repository, the solution would be pretty easy:
    when the customer ask for the version, you not only deliver the integration build, but you also
    promote it to a milestone status, for example. this promotion indicates that you should keep track of
    this version in a long period, to be able to come back to it and create a branch if needed.

    Note this is the strategy at, where a nightly build (N20080420) can be promoted to an Maintenance
    release if quality is good enough. Below I've put an extract of a presentation document from © 2006 by Alex Blewitt;
    made available under the EPL v1.0 |  2006-03-20  |

    We are now using the same naming convention at INNOVEO for our product

    Eclipse builds are of different type:

    (N) Nightly
    • Built every night (whether successful or not)
    • Used to run quality metrics and whether tests have passed
    (I) Integration
    • Used to ensure that code works together
    • Used to run quality metrics
    (M) Maintenance
    • Released at the end of each build cycle
    (R) Release
    • Released at the end of each release cycle

    Each product is given a build id,

    • Build Type (N, I, M or R)
    • Build ID (M20060118)
    • Build Label (M20060118-1600)
    • Timestamp of build (16:00 on the 18th Jan, 2006)
    • Each release corresponds to a specific build label
    • May also be known as other aliases in CVS
    • R3_1_2, vI20060118-1000, R3_1_Maintenance

    To keep the Eclipse ecosystem in step, everything is tagged

    • Part of the build process tags the current code with vI20060320
    • A build is only promoted from N->I if there are no build failures
    • A build is promoted from I->M if there are no failures and all the
      functionality works to a satisfactory level
    • A build is promoted from M->R at the end of a release cycle and
      the quality is suitably high

     On the other hand, the main drawback of this solution is that it can produce a lot of intermediate
    versions, and you will have to run some cleaning scripts in your repository...

    I will present You later how you can achieve this goal with MAVEN and Team City

  • TeamCity is a Continuous integration and build management server from JetBrains.

    As the first build step, create a custom script that reads %build.number%, and uses service messages to append the short GIT hash programmatically.


    Here’s an example using a bash script pasted right into the TeamCity GUI (Runner type: Command Line, Run: Custom Script):

    echo "#teamcity[buildNumber '#${GIT_HASH_SHORT}']"
  • I present You here some tips to deal with CVS integration into eclipse.


    • The tutorial ship with Eclipse is quite good, take a look in HELP or search (cvs) into the help for articles..


    • If You have a huge number of Projects in Your workspace, always try to have closed version of these  especially if  you are not supposed to change them.
    • Releases should follows an X.Y.Z convention where:
      • X = The major release number
        An increment of this number generally indicates a significant change to the code base. The increment may be completely incompatible with prior versions.
      • Y = The minor release number
        An increment of this number usually indicates a significant change to functionality or architecture but with a moderate to high level of backward compatibility with previous versions.
      • Z = The maintenance release number
        An increment of this number usually indicates bug fixing within the X.Y release and possibly small enhancements and limited new features. These versions are expected to be fully backwardly compatible with previous increments.

    P1X project 1, version X, in workpace
    P2Y project 2, version Y
    p3Z project 3, version Z
    P1H project 1, HEAD version

     Case A: You are continuing the development of a project...
    Your team has reach a milestone, and want to continue development of the project . Happen 98% of the time
    IF (you decide to make a change on P1_X) AND (P1_X is the latest closed version of P1) {
    Compare project P1_X with the project P1_Head;
    IF (P1_X identical to P1_Head) {
    Load P1_Head code;
    ELSE {
    IF (P1_Head code is worth loading/using) {
    Load P1_Head code;
    Compare P1_Head with P1_X, and merge changes if needed to code in workspace;
    //You have now a open edition of P1 in workspace which is a merge of P1X and P1H
    } ELSE {
    jump to case B;
    Continue development;


     Case B:  

    You want to make a patch on a project...

    • The version of the project has already been deployed or sold to customer, and
    • Your actual code may be a lot more advance, but not finished, not tested, possibly breaking interfaces of other components and
    • You prefer to continue development on the old version to reduce risks of instabilities.
    //old status of a project which have a problem/your prefer 
    Load P1_X in workspace;  (Team - replace with - choose version P1_X) 
    On P1_X, create a branch (Team - create branch - name it for ex: P1_X_b01);
    Develop, test, develop;
    Commit the branch (Team - commit : this put code in its own HEAD)
    When the branch is stable, create a version P1_X_1 for example (Team - Tag as verion)

    Decide if now if the change done on P1_X_1 are worth to bring in P1_Head, if so You will have to follow Case A