community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Non-released Dependencies
Date Mon, 28 Jul 2014 09:53:49 GMT
On 28 July 2014 10:20, Greg Stein <gstein@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.connolly@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 <gstein@gmail.com> wrote:
>>
>>> [adding dev@community, as I believe this should go there...]
>>>
>>> On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert <vhennebert@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
>>>
>>
>>

Mime
View raw message