Re: Non-released Dependencies
Greg Stein <[email protected]> Mon, 28 Jul 2014 04:20:08 -0500
| Newsgroups | gmane.comp.apache.community,gmane.comp.apache.incubator.bigtop.devel |
|---|---|
| Message-ID | <CABD8fLXzM6sJ2zAEmW-ZBTWjBe1HXrW_PAjV_3q_OSaC=uqyig__37443.594428669$1406539270$gmane$org@mail.gmail.com> |
--f46d043892c5e785c704ff3d6d32 Content-Type: text/plain; charset=ISO-8859-1 Agreed that #2 is best. (and I'll also note I was a bit slack with some commentary; releases need to be signed, so a path/revision or git-tag is not necessarily a true 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 < [email protected]> 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 <[email protected]> wrote: > >> [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 >> > > --f46d043892c5e785c704ff3d6d32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Agreed that #2 is best.<div><br></div><div>(and I'll a= lso note I was a bit slack with some commentary; releases need to be signed= , so a path/revision or git-tag is not necessarily a true release; just try= ing to get across that you need a *specific* set of source for a dependency= )</div> <div><br></div><div>Seems that Andreas is going to explore some options at = dev@pdfbox.</div><div><br></div><div>Cheers,</div><div>-g</div><div><br></d= iv></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On F= ri, Jul 25, 2014 at 9:34 AM, Stephen Connolly <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]" target=3D"_blank">stephen.alan.= [email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I think the key bit here is= that releases of Apache projects must have an associated source release an= d have been voted on by the PMC making the release.<div> <br></div><div>If the project you depend on is an independent project, you = need to remember that their -SNAPSHOT build is *not* a release. Therefore y= ou need it to become a release to include it.</div> <div><br></div><div>You therefore have three choices:</div><div><br></div><= div>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.</= div> <div><br></div><div>2. Join the dependent project and help them get to a re= lease</div><div><br></div><div>3. Find somebody outside the ASF (or at a mi= nimum not wearing an ASF hat) and get them to fork the code you want and re= lease that. Then you can depend on the non-ASF fork of the ASF project... a= gain a rude option, but perhaps less so than #1</div> <div><br></div><div>I vote you go for #2. It plays best with community whic= h is what we are here to foster</div></div><div class=3D"HOEnZb"><div class= =3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 25= July 2014 15:26, Greg Stein <span dir=3D"ltr"><<a href=3D"mailto:gstein= @gmail.com" target=3D"_blank">[email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">[adding dev@community, as I believe this sho= uld go there...]<br> <br> On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert <<a href=3D"mailto:vh= [email protected]" target=3D"_blank">[email protected]</a>><br> wrote:<br> >...<br> <br> > Hi,<br> ><br> > there's an undergoing debate in the XML Graphics project about doi= ng<br> > a release that has a dependency on a snapshot version of another<br> > (Apache, for that matter) project.<br> ><br> <br> The fact that it is an Apache project is *key* for my commentary below.<br> Don't take my words for external projects, please :-P<br> <br> <br> ><br> > I know there's a policy at Apache to not release a project that ha= s<br> > 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 th= at<br> > explicitly states it.<br> ><br> <br> That's why you can't find it... I don't recall any such "p= olicy" (over the<br> past 15+ years I've been around) ... it just isn't a good idea. Tha= t's all.<br> <br> <br> ><br> > The following link: <a href=3D"http://www.apache.org/dev/release.html#= what" target=3D"_blank">http://www.apache.org/dev/release.html#what</a> is<= 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 containin= g<br> > a snapshot binary.<br> ><br> <br> Well. You need to produce a full set of sources. No binaries. Those sources= <br> might be by-reference, but you definitely can't release a binary within= <br> your source distribution.<br> <br> Even if that other Apache project had a release you're happy with, ther= e<br> would be a source release available for it.<br> <br> <br> ><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<b= r> > revision number, is apparently not convincing enough either. Despite t= he<br> > obvious dependency nightmare that that would cause to users (and, in<b= r> > particular, Maven users and Linux distributions).<br> ><br> <br> Pause. This is not negotiable. You *must* have a source release. If you do<= br> that through a signed tarball, or through a git tag, or a Subversion<br> revision number ... all of these identify a *specific* set of source code.<= br> That satisfies the need.<br> <br> You raise some concerns about nightmares... sure. Telling users "you m= ust<br> get r123 of /some/path, for $LIBRARY" is not exactly friendly. BUT: it= <br> satisfies all release requirements. It will specify the exact dependency.<b= r> Good to go.<br> <br> <br> <br> ><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@)?<br> <br> <br> Much of this kind of stuff is "institutional knowledge" because h= aving to<br> write down "rules" and "procedures" just sucks. It is s= uch a rare event,<br> that it is best to leave it for the particular situation.<br> <br> There are no legal ramifications, if you're talking about a sibling Apa= che<br> project.<br> <br> Now... you *should not* do any sort of release of a sibling. That will<br> screw over that community. (version skew, unsupported bits, issue tracking,= <br> blah blah)<br> <br> I believe you have two options: fork their code into your project, and do<b= r> some appropriate subpackage renaming to clarify it is distinct. Or,<br> ideally, you join *their* community and help them cut a release, and then<b= r> base your code on that.<br> <br> Cheers,<br> -g<br> </blockquote></div><br></div> </div></div></blockquote></div><br></div> --f46d043892c5e785c704ff3d6d32--