Thanks for the clarification!
I’m still not sure I understand. In plain English we seem to have these
unresolved questions:
1) (Re)compiling convenience packages with modifications to binary dependencies
after the release vote: Is that kosher or not?
2) If a binary dependency is added to a convenience package (instead of being
downloaded at install time) which results in the need to modify the LICENSE /
NOTICE file that’s accompanying the convenience package, does that require a
new VOTE and release or not?
3) In our case, the binary dependency is JBurg which is used as part of the
compiler process on the client’s machine. It’s not byte code that is compiled
into the resultant binary. The literal interpretation of the text would lean
towards saying that’s a no-no. I find it hard to believe that that’s the
intent. Is there any way to better clarify this point?
Justin, please correct me if I missed any points or misrepresented any of them.
Thanks,
Harbs
On Oct 21, 2014, at 9:35 PM, Marvin Humphrey <mar...@rectangular.com> wrote:
> On Tue, Oct 21, 2014 at 6:55 AM, Harbs <harbs.li...@gmail.com> wrote:
>> The one thing I see missing from the proposed text is dependencies and
>> installers.
>>
>> Particularly this section:
>>
>> ### Compiled packages ### {#compiled-packages}
>>
>> The Apache Software Foundation produces open source software. All releases
>> are in the form of the source materials needed to make changes to the
>> software being released.
>>
>> As a convenience to users that might not have the appropriate tools to
>> build a compiled version of the source, binary/bytecode packages MAY be
>> distributed alongside official Apache releases. In all such cases, the
>> binary/bytecode package MUST have the same version number as the source
>> release and MUST only add binary/bytecode files that are the result of
>> compiling that version of the source code release.
>>
>> ---
>>
>> How do binary dependencies fit in?
>
> Thanks for the review!
>
> The sentence in question is taken nearly verbatim from the existing release
> policy document. The only changes are capitalizing "MUST" and swapping out
> "may only" for "MUST ONLY":
>
> http://www.apache.org/dev/release#what
>
> In all such cases, the binary/bytecode package must have the same version
> number as the source release and may only add binary/bytecode files that
> are the result of compiling that version of the source code release.
>
> This is in keeping with the goal of the initiative: "to clarify policy,
> NOT TO CHANGE IT."
>
> My interpretation of that passage is that a liberal view of the word
> "compiling" allows the bundling of binary dependencies. Sometimes "compiling"
> is taken to mean a compilation/translation phase which is distinct from
> linking, and other times "compiling" encompasses linking (either static or
> dynamic). The more expansive definition is consistent with how that
> policy has traditionally been applied.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
