ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Klaas Prause <>
Subject AW: Versioning Best Practices?
Date Tue, 24 Nov 2009 08:29:14 GMT

I can only answer a few of your questions. This is what we figured out for our projects.

The basics:
We have around 50 projects not all related to each other but in the end it is the same as
you describe in your structure.

We have our builds in three states: integration, milestone and release
Our version pattern is:
Integration - major.minor.fix-devtimestamp --> 1.2.0-dev20091124121032
Milestone - major.minor.fix-alphatimestamp --> 1.2.0-alpha20091124121032
Release - major.minor.fix --> 1.2.0

We are using SVN so:
Integration = trunk (build on CI-Server)
Milestone = branches/* (build on CI-Server)
Release = tags/* (only build manually for a release)

All our internal dependencies reference to the newest major.minor.fix version, i.e.
"1.2.0+" for the example above.
We have different resolver chains for integration, milestone and release so that the newest
most stable version is used.
Integration chain - release, milestone, integration
Milestone chain - release, milestone
Release chain - release

The chains prevent problems in resolving wrong artifacts that are not allowed for the current
build state.

With this setup, we do not need to clean a cache. The build numbers are timestamped, so you
do not need to increment the fix revision for any build but still get different artifacts.

Andrew Thorburn schrieb:
> There are some related problems with IvyDE (the Eclipse plug in), but
> I'm not sure if I should be asking those on this list?

The above schema is working for us with ivyDE.

> Also, the other thing I'm wondering about, is how do you folks roll
> your version numbers?

Our BuildApplication scripts are incrementing the minor version number when branching. The
dependencies to other projects stay the same, so we have (and want to) manually update the
dependencies if we need a newer version of some of our internal libs.

View raw message