incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
Date Thu, 29 Mar 2012 14:22:14 GMT
On 29 March 2012 15:09, Marcel Offermans <marcel.offermans@luminis.nl> wrote:
> On Mar 29, 2012, at 15:07 , Bertrand Delacretaz wrote:
>> On Thu, Mar 29, 2012 at 2:41 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>>> ...It seems like Roy is much more categorical about this. Assuming I
>>> understand his point correctly, *no* binary dependencies are
>>> acceptable within a source tar ball.
>
> Let's see if I still correctly follow this discussion. So far we seem to have consensus
about the fact that:
>
> a) the only official releases that Apache does are source releases, and
> b) source releases must not contain binaries (of any dependencies).
>
> So far so good, and the only suggestion I have in this area is that we should make a
more clear distinction between what we officially release (and vote on) and anything else
we might provide for convenience. Just taking a look at www.apache.org/dist/ reveals that
it contains both, and a lot of the time not clearly separated, which is confusing. Furthermore,
it seems that some projects have more than just their latest release there (which is another
matter, not related to this discussion).
>
> I propose something like:
>
>  * www.apache.org/dist/[project]/ for the latest source release that was voted on
>  * www.apache.org/bin/[project]/ for "convenience" binaries, etc.

An alternative, which many projects already use, would be:

* www.apache.org/dist/[project]/source/ for the latest source release
that was voted on
* www.apache.org/dist/[project]/binaries/ for "convenience" binaries, etc.

This makes it a bit easier to find the binaries from the source and vice-versa.

>>> What I don't quite (yet) understand is how a reference like
>>> "junit:junit:4.10" to a download service maintained by a third party
>>> is more acceptable than directly including the referenced bits...
>>
>> I think the difference is that by saying "get junit:junit:4.10 to
>> build this" we put the burden on our users to make sure they get the
>> right bits, either by building them themselves from the junit sources,
>> or trusting whoever provides them.
>>
>> By shipping those bits ourselves instead, we would take the
>> responsibility on our shoulders, which we don't want.
>
> Since we are allowed to somehow reference an artifact (as long as it has a license that
is compatible with what we do) and have a build script download it, my question is, must this
artifact come from a location *outside* of Apache, or are we also allowed to reference these
binaries that were provided for convenience by our own projects?
>
> Related, how about binaries that are in a separate part of the SVN tree of a project
(a part that is not released)? Can we reference and download (or checkout) those as part of
a build script?
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message