ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: latest-revision latest-strategy & integration versions
Date Wed, 25 Aug 2010 16:58:15 GMT
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.clitheroe@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 <mgitman@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 <mgitman@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.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message