On 28 July 2014 10:20, Greg Stein <gst...@gmail.com> wrote: > Agreed that #2 is best. > > (and I'll also note I was a bit slack with some commentary; releases need > to be signed,
Also source releases must be published via the ASF mirror system. > so a path/revision or git-tag is not necessarily a true s/necessarily// > release; just trying to get across that you need a *specific* set of source > for a dependency) > > Seems that Andreas is going to explore some options at dev@pdfbox. > > Cheers, > -g > > > > On Fri, Jul 25, 2014 at 9:34 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> 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 >>> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
