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 Eclipse.org, 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  |  http://www.rcpapps.org/

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

You might like also

Fetching artifact programmatically through REST/API in Nexus 3.x
There is so many case where it is desirable to pull down artifact from Sonatype #Nexus using REST API, unfortunately #Nexus 3.x Rest API are still under development... Some use cases in Nexus 2.x: You have a script that uses #REST call to pull down the LATEST maven artifacts every night from Nexus and deploys them. You make extensive use of the #REST API in all your puppet modules You use the #Atlassian #Puppet module for Nexus for creating repository, …
996 Days ago
When working with many feature/release/bugix/hotfix branches, it is a bad idea to start changing the pom version as this will create merge conflicts using pull request. this plugin allow you to keep in ALL branches the same pom version for all your projects, for example MASTER-SNAPSHOT the version will be derived from branch name automagically :-) You may want to read more first these 2 short articles Update Maven pom version on GIT checkout in TeamCity maven-release-plugin with GIT git-branch-renamer-maven-plugin …
1008 Days ago
Review: Getting Started with Apache Maven by Russell Gold
Some time ago I was asked if I would like to write a review about one of the new video courses from Packt Publishing. It was "Getting Started with Apache #Maven" http://bit.ly/1fycmpP by Russell Gold and since I have been using Maven for some years now (since 2007) and did publish some articles myself, I thought it would be nice to help them promote Apache #Maven. The course is organized in eight chapters, forty videos with a length between two …
2195 Days ago
Update Maven pom version on GIT checkout in TeamCity
Here is a solution to the following problems Deriving #Maven artifact version from #GIT branch, Update pom version on #GIT checkout automatically, Add the ability to use Pull request with Apache #Maven. You have a workflow requirement that require you to have the artifact version of a module externally defined from the current branch in #GIT. For example You want to start working on a new feature branch “feature-memory-improvement”, so you branch from master a new branch named feature/feature-memory-improvement Having …
2200 Days ago
Easily Compress Web Application Resources with EhCache
Resources such as #JavaScript and CSS files can be compressed before being sent to the browser, improving network efficiencies and application load time in certain case. If you are not using Apache with mod_deflate or nginx in front of your web application, you may need to implement resources compression yourself…. Wait! don’t start writing your own filter to compress files like CSS, html, txt, javascript it is way more difficult than you think to properly handle http response headers and …
2682 Days ago
Tomcat 7 and Apache Maven
Here is 3 different way to control the lifetime a local Tomcat 7 container using Apache #Maven. A typical scenario would be to start a servlet container prior to running integration tests (Selenium, SAHI or using any other framework you can think of ) With the following examples, you will be able to start an instance of Tomcat 7 running your web application in the pre-integration-test phase and stop the instance in the post-integration-test phase. You can also decide to …
2682 Days ago
Apache Maven copy local file to a remote server server using SSH
I will show you in an Apache #Maven configuration file how to copy files to server each time the package phase is executed. Solution with Ant SCP task This snippet of code is a ready to use code that make use of Apache Ant task scp, Just put this snippet of code in your #Maven module where the assembly is executed or anywhere else to push all tar.gz files to a server just run a #maven mvn package, you can …
2870 Days ago
Apache M2Eclipse: Get rid of Duplicate resources when opening resources and types
In this small post, I’ll show you how to remove duplicated resources in the Open Resource view of #Eclipse Eclipse – M2Eclipse – Subversive …
2876 Days ago
Apache Maven 3 Cookbook
  First a big thanks to Packt Publishing for having sent me this book to review! I did enjoy going through this book, while I did not learn a lot of new stuff (I am using Apache #Maven daily since 2006!), I found it to be concise and would recommend it anytime to any of my colleagues. But let’s go through my review of this cookbook of over 50 recipes towards optimal #Java Software Engineering with #Maven 3: Apache #Maven …
3018 Days ago
Apache Maven 3 Cookbook Review
Thanks to Packt Publishing for having sent me this book to review. I will publish a review in the next coming days Grasp the fundamentals and extend Apache #Maven 3 to meet your needs Implement engineering practices in your application development process with Apache #Maven Collaboration techniques for Agile teams with Apache #Maven Use Apache #Maven with #Java, Enterprise Frameworks, and various other cutting-edge technologies Develop for Google Web Toolkit, Google App Engine, and Android Platforms using Apache #Maven You …
3064 Days ago