incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <>
Subject Fwd: Draft incubator report
Date Thu, 07 Feb 2019 08:38:14 GMT
Sorry I meant to send this to the list but only Dave got it.

> Begin forwarded message:
> From: Justin Mclean <>
> Subject: Re: Draft incubator report
> Date: 6 February 2019 at 8:48:46 am AEDT
> To: Dave Fisher <>
> Hi,
>> Yes, that is better, but here is the next challenge. For distribution channels like
Maven, NPM, etc which some projects use to stage prospective releases how do we recommend
that projects stay within the available, but not advertised rule? I think somewhere some guidance
is needed.
> When this was dicusssed (see [1]) it was stated:
> "There are an unbounded number of such downstream channels, and there is no way we are
going to formulate specific policies for all of them.”
> But it’s really not that hard and is covered by existing policy. [2][3]
> But some examples may help:
> - With GitHub I would not expect any releases that appear on the release page (<apache
project>/releases)  to contain unreleased code or be compiled from such code. Only releases
compiled from official approved source releases should be listed.
> - With npm if I go "npm install <apache project>” I only expect to get the latest
official release based on an approved offical source release. To get a RC or nightly I’d
need to "npm install <apache project>@sometag”
> - With docker hub, if I go "docker pull <apache project>” I’d only expect to
get the latest official approved version and not contain any unapproved code. I’s expect
RCs to be tagged in some way and nightly with their commit hash or something similar.
> - For PiPy I expect "pip install <apache project>” to install the lasted official
approved release and no contain any unapproved code. And I not expect to see any releases
on the release history page (<apache project>/#history) to
contain unapproved code.
> I think with most platforms you can work out what to do so that you are not advising
nightlys or release candidates to the general public.
> And of course your ASF project site shouldn't include any links to unapproved releases
as mentioned in [2] "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”. Note it also says "If you find that the general public are downloading
such test packages, then remove them.” so care still needs to be taken.
> Thanks,
> Justin
> 1.
> 2.
> 3.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message