+1 (to this and Jochen's response) Roman was explicit in his question about "clearly identifiable non-release artifacts available to the general public". We can debate words on a page forever, or we can work with the intent and get on with producing software.
There is plenty of precedent here (including the oldest project in the foundation). My summary of the intent: Don't advertise automated "non-release" artifacts in such a way that people may accidentally stumble across them and believe them to be production releases. That's it. Ross Sent from my Windows Phone ________________________________ From: Emmanuel Lécharny<mailto:elecha...@gmail.com> Sent: 6/24/2015 7:38 AM To: general@incubator.apache.org<mailto:general@incubator.apache.org> Subject: Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts Le 24/06/15 14:04, Marvin Humphrey a écrit : > On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH) > <ross.gard...@microsoft.com> 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
