qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: [java]: compilation failure on M2 and trunk
Date Wed, 03 Oct 2007 18:31:19 GMT
Rupert Smith wrote:
> I think that the issue of snapshots can be graded into different degrees.
> There are snapshots in the main build artefacts, in the test artefacts, and
> in the build scripts themselves. Snapshots in the main artefacts being the
> worst.
> However, I think that there are situations where even that could be
> acceptable. A hypothetical example. Lets us suppose that we find a horrible
> bug in say MINA. Its two weeks till the next MINA release, but the next Qpid
> release is certainly going to be months away, the code base is heavily under
> development. The MINA bug is holding development up, so we temporarily pick
> up a snapshot of it, create a JIRA on the forthcoming Qpid release to ensure
> that the snapshot is resolved before the release. Do remember, that you can
> also pin to a specific snapshot version by including the full snapshot
> timestamp if needed, but that this still does not guarantee repeatability,
> as snapshots are held outside the central repo, and their maintainers could
> remove them at any time.

I don't think this as a particularly realistic situation. I'm finding it 
hard to imagine what kind of MINA bug would occur that is low enough 
priority for MINA developers to wait months to release a fix for, and 
yet severe enough to block all other forms of development on Qpid.

The only similar scenario I can think of is the way security updates are 
handled by OS vendors since that is the one case where we truly can't 
wait for an upstream bug fix, however this wouldn't be a concern in your 

> One solution to the above, might be, that whenever a snapshot is used a copy
> of the offending jar should be checked in the Apache svn, under a directory
> that is set up as a local mvn repository on the build.

The way OS vendors handle this when it truly can't be avoided is to use 
a patch against a well defined version of the source.


View raw message