ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Brown <>
Subject Re: Versioning Best Practices?
Date Mon, 30 Nov 2009 15:57:21 GMT
Jumping in late to the party here...

Our versioning pattern is major.minor.revision, which is populated using two
variables major.minor are set at a release level (and can be calculated to a
branch in Subversion), and revision matches the last-changed revision of the
particular module.

Works well, except in the case of 'container' artifacts (WARs, EARs, the
like) which don't change much.  We end up publishing those over & over with
changing contents (jars).

We're _going_ to be doing something like one of
these days, but just haven't gotten around to it.



On Tue, Nov 24, 2009 at 12:29 AM, Klaas Prause <> wrote:

> Hi,
> 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.
> Regards
> Klaas

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message