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: http://ant.apache.org/ivy/history/latest-milestone/concept.html#change 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. HTH Keith -----Original Message----- From: Andrew Thorburn [mailto:[email protected]] Sent: 24 November 2009 06:34 To: [email protected] 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 company-core partner-company-core_1 partner-company-core_2 product-core client-end-product 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 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... 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
