incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
Date Wed, 24 Jun 2015 14:37:55 GMT
Le 24/06/15 14:04, Marvin Humphrey a écrit :
> On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
> <> wrote:
>> There is nothing preventing "clearly identifiable non-release artifacts
>> available to the general public".
> The Releases Policy page forbids it explicitly:
>     During the process of developing software and preparing a release, various
>     packages are made available to the developer community for testing
>     purposes. **Do not include any links on the project website that might
>     encourage non-developers to download and use nightly builds, snapshots,
>     release candidates, or any other similar package.** The only people who are
>     supposed to know about such packages are the people following the dev list
>     (or searching its archives) and thus aware of the conditions placed on the
>     package. If you find that the general public are downloading such test
>     packages, then remove them.
>     Under no circumstances are unapproved builds a substitute for releases. If
>     this policy seems inconvenient, then release more often. Proper release
>     management is a key aspect of Apache software development.
> What differentiates the "general public" from "developers" is whether they are
> aware of the conditions placed on the artifacts and thus exercising informed
> consent.
> Those conditions are are not limited to instability of the codebase, but also
> whether the artifacts meet Apache's licensing and legal requirements for
> releases.

IMO, 'public' here means : 'exposed on the project's web site'.

Whatever is built, and pushed on temporary spaces that are not
mentionned on the project's web site does not enter in this category.

The release policy does not state this is forbidden to produce those
non-release builds, nor to push it somewhere reachable to anyone, but
forbid advertizing about it (announce@a.o, or a news on the project's
web site).

What is important here is the spirit, not the letter : we want to be
sure that those who download those non-release packages *know* what they
are doing and what they are exposing themselves to.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message