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
