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 major.minor.revision.build one of these days, but just haven't gotten around to it. h2h, ~Tim On Tue, Nov 24, 2009 at 12:29 AM, Klaas Prause <[email protected]> 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 >
