Re: Non-released Dependencies
Greg Stein <[email protected]> Fri, 25 Jul 2014 09:26:11 -0500
| Newsgroups | gmane.comp.apache.community,gmane.comp.apache.incubator.bigtop.devel |
|---|---|
| Message-ID | <CABD8fLWnMCpfdz+km3PXMGzJDTjhE8DicTfJFwLkwAkzWaEZYw__26381.3423495323$1406298416$gmane$org@mail.gmail.com> |
--001a11c35470e5eca604ff055a47 Content-Type: text/plain; charset=ISO-8859-1 [adding dev@community, as I believe this should go there...] On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert <[email protected]> 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 --001a11c35470e5eca604ff055a47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">[add= ing dev@community, as I believe this should go there...]</div><div class=3D= "gmail_quote"><br></div><div class=3D"gmail_quote">On Fri, Jul 25, 2014 at = 6:06 AM, Vincent Hennebert <span dir=3D"ltr"><<a href=3D"mailto:vhennebe= [email protected]" target=3D"_blank">[email protected]</a>></span> wrote:<= /div> <div class=3D"gmail_quote">>...<br><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br= > <br> there’s an undergoing debate in the XML Graphics project about doing<= br> a release that has a dependency on a snapshot version of another<br> (Apache, for that matter) project.<br></blockquote><div><br></div><div>The = fact that it is an Apache project is *key* for my commentary below. Don'= ;t take my words for external projects, please :-P</div><div> </div><b= lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex"> <br> I know there’s a policy at Apache to not release a project that has<b= r> non-released dependencies. The problem is, I don’t know how I know<br= > that... I cannot seem to be able to find any official documentation that<br= > explicitly states it.<br></blockquote><div><br></div><div>That's why yo= u 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.</div> <div> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"> <br> The following link: <a href=3D"http://www.apache.org/dev/release.html#what"= target=3D"_blank">http://www.apache.org/dev/<u></u>release.html#what</a> i= s<br> apparently not convincing enough. I’m answered that this concerns our= <br> own project but that it’s fine to do an official release containing<b= r> a snapshot binary.<br></blockquote><div><br></div><div>Well. You need to pr= oduce a full set of sources. No binaries. Those sources might be by-referen= ce, but you definitely can't release a binary within your source distri= bution.</div> <div><br></div><div>Even if that other Apache project had a release you'= ;re happy with, there would be a source release available for it.</div><div= > </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"> <br> Saying that every binary artefact has to be backed by source code and<br> that, in the case of a snapshot, we have to point to some Subversion<br> revision number, is apparently not convincing enough either. Despite the<br= > obvious dependency nightmare that that would cause to users (and, in<br> particular, Maven users and Linux distributions).<br></blockquote><div><br>= </div><div>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 Subver= sion revision number ... all of these identify a *specific* set of source c= ode. That satisfies the need.</div> <div><br></div><div>You raise some concerns about nightmares... sure. Telli= ng users "you must get r123 of /some/path, for $LIBRARY" is not e= xactly friendly. BUT: it satisfies all release requirements. It will specif= y the exact dependency. Good to go.</div> <div><br></div><div> </div><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> Does anybody have any official reference to point at, that I may have<br> missed? More convincing arguments, legal reasons (should I forward to<br> legal-discuss@)?</blockquote><div><br></div><div>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.</div> <div><br></div><div>There are no legal ramifications, if you're talking= about a sibling Apache project.</div><div><br></div><div>Now... you *shoul= d not* do any sort of release of a sibling. That will screw over that commu= nity. (version skew, unsupported bits, issue tracking, blah blah)</div> <div><br></div><div>I believe you have two options: fork their code into yo= ur project, and do some appropriate subpackage renaming to clarify it is di= stinct. Or, ideally, you join *their* community and help them cut a release= , and then base your code on that.</div> <div><br></div><div>Cheers,</div><div>-g</div><div><br></div></div></div></= div> --001a11c35470e5eca604ff055a47--