I think the key bit here is that releases of Apache projects must have an associated source release and have been voted on by the PMC making the release.
If the project you depend on is an independent project, you need to remember that their -SNAPSHOT build is *not* a release. Therefore you need it to become a release to include it. You therefore have three choices: 1. Fork the code into your project and do a big-bang release... a rude option but once it's in your project your PMC can vote to release it. 2. Join the dependent project and help them get to a release 3. Find somebody outside the ASF (or at a minimum not wearing an ASF hat) and get them to fork the code you want and release that. Then you can depend on the non-ASF fork of the ASF project... again a rude option, but perhaps less so than #1 I vote you go for #2. It plays best with community which is what we are here to foster On 25 July 2014 15:26, Greg Stein <gst...@gmail.com> wrote: > [adding dev@community, as I believe this should go there...] > > On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert <vhenneb...@gmail.com> > wrote: > >... > > > Hi, > > > > there's an undergoing debate in the XML Graphics project about doing > > a release that has a dependency on a snapshot version of another > > (Apache, for that matter) project. > > > > The fact that it is an Apache project is *key* for my commentary below. > Don't take my words for external projects, please :-P > > > > > > I know there's a policy at Apache to not release a project that has > > non-released dependencies. The problem is, I don't know how I know > > that... I cannot seem to be able to find any official documentation that > > explicitly states it. > > > > That's why you can't find it... I don't recall any such "policy" (over the > past 15+ years I've been around) ... it just isn't a good idea. That's all. > > > > > > The following link: http://www.apache.org/dev/release.html#what is > > apparently not convincing enough. I'm answered that this concerns our > > own project but that it's fine to do an official release containing > > a snapshot binary. > > > > Well. You need to produce a full set of sources. No binaries. Those sources > might be by-reference, but you definitely can't release a binary within > your source distribution. > > Even if that other Apache project had a release you're happy with, there > would be a source release available for it. > > > > > > Saying that every binary artefact has to be backed by source code and > > that, in the case of a snapshot, we have to point to some Subversion > > revision number, is apparently not convincing enough either. Despite the > > obvious dependency nightmare that that would cause to users (and, in > > particular, Maven users and Linux distributions). > > > > Pause. This is not negotiable. You *must* have a source release. If you do > that through a signed tarball, or through a git tag, or a Subversion > revision number ... all of these identify a *specific* set of source code. > That satisfies the need. > > You raise some concerns about nightmares... sure. Telling users "you must > get r123 of /some/path, for $LIBRARY" is not exactly friendly. BUT: it > satisfies all release requirements. It will specify the exact dependency. > Good to go. > > > > > > > Does anybody have any official reference to point at, that I may have > > missed? More convincing arguments, legal reasons (should I forward to > > legal-discuss@)? > > > Much of this kind of stuff is "institutional knowledge" because having to > write down "rules" and "procedures" just sucks. It is such a rare event, > that it is best to leave it for the particular situation. > > There are no legal ramifications, if you're talking about a sibling Apache > project. > > Now... you *should not* do any sort of release of a sibling. That will > screw over that community. (version skew, unsupported bits, issue tracking, > blah blah) > > I believe you have two options: fork their code into your project, and do > some appropriate subpackage renaming to clarify it is distinct. Or, > ideally, you join *their* community and help them cut a release, and then > base your code on that. > > Cheers, > -g >
