ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Hatton" <>
Subject RE: Versioning Best Practices?
Date Tue, 24 Nov 2009 13:02:25 GMT
Hi Andrew,

It sounds like you need changing="true" on the dependencies for your WAR
file. As I understand it, the default behaviour of Ivy is (not unreasonably)
to look for version a.b.c of a dependency firstly in the cache, and if it
finds it, well that must be it. Setting changing="true" allows for the
possibility that "version" a.b.c might not actually be a fixed release.

More info here:

Having said that, I initially went down that road but quickly reverted to
using Ivy with an earlier (non-Ivy) solution for version numbering, which
was, yes, to give every build a distinct number. I now have version numbers
a.b.c-dev-[timestamp]-[user] which seems to work for me. [timestamp] is
formatted year-month-date so the standard "latest" rules work fine with it.
When I come to do a release build, the version number is just a.b.c, then c
gets incremented (manually for now). The "Latest Strategy" section on that
same page above explains that Ivy has built-in special handling of version
numbers that contain "dev" or "rc" in them. I generally have a dependency on
"latest.${ivy.publication.status}" which means that an integration build can
depend on another module with any status, but a release build can only
depend on other release builds.


-----Original Message-----
From: Andrew Thorburn [] 
Sent: 24 November 2009 06:34
Subject: Versioning Best Practices?

I'm struggling to come up with the best way to handle the various versions
of the various different JARs we have floating around. We've recently
transitioned to Ivy from a "SVN super-project" approach, where everything
(3rd party dependencies, internal company projects,
etc) were all in one great big project. Made things tricky, oddly enough.

Anyway, we now have the following projects


Where company-core is a very generic set of utility projects that can be
shared between all projects, partner-company-core_1/2 is a set of interfaces
to external companies. Some clients may use them, some clients may not.
product-core is the client-agnostic code, and the client-end-product is all
the client-specific code bundled up into a WAR file and actually released.
It may contain any or all of the other projects.

What I'm having problems with is the versioning of the first 4 libraries.
Here is my process at the moment:

1 - Make a change.
2 - Whine about lack of unit tests.
3 - Compile the code and make a JAR with Ant.
4 - Publish locally with Ivy.
5 - Make and deploy the WAR.
6 - Realize it doesn't have my updated code, grumble, clear the cache and do
it again.
7 - Test.

Rinse and repeat above steps.

The problem comes in at step 6, really. What I would like is to be able to
publish a new version of the code to my local repository, with the same
version number (and maybe a qualifier, like -dev), and not have to clear the
cache when Ivy resolves the dependencies for my WAR.

Well, that's not quite true. I'd really like to have proper unit tests, so I
don't *have* to deploy it to test it. Unfortunately, that's not practically
possible at the moment.

Given that, what am I missing? I'm sure I'm doing something in a
less-than-optimal manner (maybe I've just missed something in my ivy
settings file?), but I can't see what it is. I'd really, really appreciate
some advice here...

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?

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

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...

On the other hand, if I *don't* roll the version number every time we do a
release to Test, then I'm going to have no idea what's in production, as
there'll be different copies of the JAR with the same version number but
different contents... Auditing nightmare!

Finally, how do you handle things like the '-dev' qualifier? Do you create a
project, start committing everything to Trunk, eventually decide to roll a
release, update the revision to remove the '-dev'
tag, commit, release, then roll the version number, add the '-dev' tag and
commit back to trunk? It just seems like an awful lot of steps to me, and it
seems like something isn't quite right...

Obviously, the best solution is something only we can decide, but I am very
interested in other peoples opinions on this, and you may provide a
suggestion that I wouldn't have thought of.

Many thanks,

- Andrew Thorburn

View raw message