Awesome. Thanks, Geoff. Whenever you get back from your travels, I'd be curious to know if you had to specify your own latest-revision strategy to get this working.
If anyone else out there is prolifically versioning integration builds, whether with a buildnumber or a timestamp, how'd you get that working? Did you have to define your own latest-revision strategy? Now that I think of it, one very simple approach is to just prolifically version all integration builds, including those on a developer machine. For this, you don't even need a special suffix. So you might produce: 2.0-201008250832 2.0-201008250842 etc. And then in dependencies you can ask for: rev="2.0-+" (assuming you know you want an integration version) The only downside to this approach is that each developer is producing a new revision on their local machine every time they do a publish. This seems like overkill, but maybe it's not such a bad thing. Maybe it's a good thing if you want to compare how a change affects a dependency's behavior. This looks like what happens with Geoff's codegeo project. Developer builds will prolifically version with the *-SNAPSHOTx auto-incrementing. This raises the potential for a conflict if a developer build produces *-SNAPSHOT5 based on ivy:buildnumber because the latest version in the shared repo is *-SNAPSHOT4 and then subsequently the shared repo gets its own *-SNAPSHOT5. On Tue, Aug 24, 2010 at 2:19 PM, Geoff Clitheroe <g.clithe...@gmail.com>wrote: > Hi Mitch, > > I'm heading for a plane and will be away for a while. This may be useful - > how we're doing snapshots (for this repo anyhow) > > http://codegeo.org/confluence/display/codegeo/Publishing > > http://codegeo.org/repos/codegeo/build/trunk/build-base.xml > > > Cheers, > Geoff > > > On Wed, Aug 25, 2010 at 3:14 AM, Mitch Gitman <mgit...@gmail.com> wrote: > > > Bumping this to the top to see if I can get any takers. I'm particularly > > interested in seeing how anyone was able to work a timestamp or > buildnumber > > into the mix and whether that needed a custom revision strategy. > > > > On Sun, Aug 22, 2010 at 4:19 PM, Mitch Gitman <mgit...@gmail.com> wrote: > > > > > I'm grappling with some of the choices surrounding integration > versions. > > > > > > One assumption I want to make is that non-integration versions—versions > > > that represent releases—do not have any special suffixes. So I would > > release > > > version 2.0 of something rather than 2.0-FINAL or 2.0-RELEASE or > > something > > > like that. > > > > > > I do want to use a special suffix to represent integration versions. > One > > > combination that makes sense to me is -DEV and -CI. It seems that I > > should > > > specify something like the following in my Ivy settings: > > > <latest-revision name="mylatest-revision" > > > usedefaultspecialmeanings="false"> > > > <specialMeaning name="CI" value="-2"/> > > > <specialMeaning name="DEV" value="-1"/> > > > </latest-revision> > > > > > > Does this look right? Notice no hyphen prefix. And as long I'm > mentioning > > > the suffixes -DEV and -CI, anyone care to suggest a better suffix or > > > combination? Of course there's always -SNAPSHOT. > > > > > > Now suppose I want to do prolific versioning where each integration > > version > > > gets its own timestamp. It seems like overkill to do prolific > versioning > > on > > > publishes on a developer machine. Only for the CI server do I only want > > to > > > produce a unique, timestamped version on each publish. So I want to > have > > the > > > ordering from newest to oldest go something like: > > > 1. 2.1-DEV on developer machine > > > 2. 2.1-CI-201008221522 on CI-published repository > > > 3. 2.1-CI-201008220801 on CI-published repository > > > 4. 2.1-CI-201008201948 on CI-published repository > > > 5. 2.0 on release repository > > > > > > Do these look like reasonable conventions, or could someone recommend a > > > better convention for producing a unique version from each successful > CI > > > build? > > > > > > If these conventions do look reasonable, how do I incorporate the extra > > > timestamp suffix into my latest-revision latest-strategy in Ivy > settings > > to > > > ensure that CI versions get ordered by timestamp but still get treated > as > > > older than DEV and release builds? > > > > > > P.S. I need to go back over some old ivy-user threads on this topic. > > > > > >
