ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juha Ranta <juha.ra...@iki.fi>
Subject Re: Versioning Best Practices?
Date Wed, 25 Nov 2009 14:19:19 GMT



ipsi wrote:
> 
> Also, the other thing I'm wondering about, is how do you folks roll
> your version numbers?
> 
> e.g. Once you have made a release, do you manually increment the
> version number by one? Do you have a script that does it all for you?
> Again, this is something I'm not really sure how to deal with.
> 
> Should I be updating the version number every time I publish to my
> local repository? That seems a little insane, and means I'll
> eventually end up with a build number like 1.1.1841, which is a little
> absurd, and makes them a little meaningless. Also major potential for
> conflicts with other developers.
> 
> Should I just roll the version number every time changes I've made to
> it need to go to Test? That seems like the best idea, especially since
> the WAR that goes to Test may end up being the WAR that goes to
> prod...
> 

Other people have already posted similar techniques for generating the
versions, but what we currently do:

For local builds to developers' local repository, we use a timestamp in the
version. For instance, "local.[timestamp]", such as "local.200911351433".
The repositories are also configured so that if there's published modules in
the local repository, they'll override the versions in the public
repositories (I think this may have been the default configuration in Ivy
examples). 

For more official builds, the project root has major and minor versions in
an Ant property file. These versions are also checked to the SCM system. The
CI builds triggered by Hudson use these values to generate the version
number and also appends a Hudson buildnumber. For instance,
[major].[minor]-dev[hudsonbuildnumber]. That is, the CI builds won't change
the major and minor versions on the SCM system; this would in fact create a
build loop with the CI server. ;)

When a release build is done, the major and minor versions in the Ant
properties file are used. For instance, 10.3. At the same time, the major
and/or minor versions in the properties file are incremented and committed
to the SCM system. There are Ant tasks such as "buildnumber" and
"propertyfile" to help with incrementing the numbers. 

So for instance, a project may have CI builds such as 10.3-dev12,
10.3-dev13, 10.3-dev14, etc. When a release build is done, it gets the
number 10.3. The CI builds after the release build get numbers 10.4-dev15,
10.4-dev16, etc. This way it's quite easy to see the relationships between
the release builds and the CI builds, and it's also quite easy to see which
Hudson build corresponds to which released artifacts. 

Juha


-- 
View this message in context: http://old.nabble.com/Versioning-Best-Practices--tp26491097p26513407.html
Sent from the ivy-user mailing list archive at Nabble.com.


Mime
View raw message