Differences between revisions 6 and 7
Revision 6 as of 2019-02-10 03:03:21
Size: 4995
Comment: added SHOULD line and update GItHub as it seems it auto create releases based on tags
Revision 7 as of 2019-02-11 20:48:42
Size: 5231
Comment: minor edits and added all PPMC members must have access to administer the platform
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
 * An incubating disclaimer must be clearly displayed where the artefacts are made available.
Line 11: Line 10:
 * An incubating disclaimer must be clearly displayed where the artefacts are made available.
 * All PPMC members must have access to administer the platform and the credentials recorded where any PPMC member can access them.
Line 13: Line 14:
These SHOULD be followed unless the podling has permission from the IPMC. These SHOULD be followed unless the podling has permission from the IPMC to do otherwise.
Line 15: Line 16:
If any podling is found not to comply they will be asked to fix it, if a fix doesn’t happen with a week they will be asked to remove the offending artefact(s), if a podling commits serial offences or fails to remove artefacts when asked to within a week they will be banned from using that distribution mechanism altogether. The IPMC reserves the right to ask INFRA to remove the artifact if the podling doesn't follow these guidelines. If any podling is found not to comply they will be asked to correct it, if that doesn’t happen with a week they will be asked to remove the offending artefact(s), if a podling commits serial offences or fails to remove artefacts when asked to within a week they will be banned from using that distribution mechanism altogether. The IPMC reserves the right to ask INFRA to remove the artifact if the podling doesn't follow these guidelines.
Line 29: Line 30:
 * The release page must not contain release candidates, nightly or snapshots releases that have not been tagged as prereleases.  * The release page must not contain release candidates, nightly or snapshots releases that have not been tagged as prereleases. (Actual not possible as GitHub turns any tag into a release and displays it there.)

Guidelines to help you comply with the ASF release and distribution policies

DRAFT DRAFT DRAFT DRAFT

In addition to the Apache mirror system incubating projects may distribute artefacts on other platforms as long as they follow these general guidelines:

  • Source releases and convenience binaries need to be made from IPMC and PPMC approved ASF releases.
  • Release candidates, nightlys and snapshots must not be advertised to the general public.
  • Apache project branding and naming needs to be respected.
  • It should be clear that the artefact is under the ALv2 license.
  • An incubating disclaimer must be clearly displayed where the artefacts are made available.
  • All PPMC members must have access to administer the platform and the credentials recorded where any PPMC member can access them.
  • Where possible these artefacts should not be referred to as releases.

These SHOULD be followed unless the podling has permission from the IPMC to do otherwise.

If any podling is found not to comply they will be asked to correct it, if that doesn’t happen with a week they will be asked to remove the offending artefact(s), if a podling commits serial offences or fails to remove artefacts when asked to within a week they will be banned from using that distribution mechanism altogether. The IPMC reserves the right to ask INFRA to remove the artifact if the podling doesn't follow these guidelines.

Motivation

The ASF is responsible for providing software which can be used in accordance with our license. Code or artefacts built from code without clean IP can mean that code that doesn't belong to us slips into users projects. This would expose our users and the ASF to the risk of lawsuite. One purpose of the incubating process and its release process is to ensure that our users can trust our projects. Releasing artefacts built from code that hasn't been approved by the IPMC circumvents this process. It robs the PPMC of learning opportunities. It increases the likelihood that we might accidentally betray the trust of our users.

At the same time binary artefacts on automated distribution platforms are important to our users for a wide variety of reasons. This policy is intended to balance these priorities. If you believe you have a case in which this policy is inadequate to your situation please bring this to our attention by mailing either general@incubator.apache.org or private@incubator.apache.org

GitHub

` Artefacts show up on https://github.com/apache/incubator-<project>/releases

To comply with ASF release and distributions please ensure the following:

  • Any releases need to include the text of the incubation disclaimer.
  • The release page must not contain release candidates, nightly or snapshots releases that have not been tagged as prereleases. (Actual not possible as GitHub turns any tag into a release and displays it there.)

  • Any releases that exist before coming into incubation need to be clearly described on the release page and tagged as such on https://github.com/apache/incubator-<project>/tags.

  • Release candidates, nightlys or snapshots releases can be tagged and appear on https://github.com/apache/incubator-<project>/tags.

Docker

Artefacts need to be placed in https://hub.docker.com/r/apache/<project> or https://hub.docker.com/u/apache<project>/<project>

To comply with ASF release and distributions please ensure the following:

  • The overview should include the incubator disclaimer.
  • The docker file (if it exists) should include an ASF header.
  • The docker file (if it exists) should include the incubator disclaimer.
  • docker pull apache/<project> should not install an artefact containing unapproved code.

  • Release candidates, nightlys or snapshots need to be clearly tagged.
  • The latest tag should not point to an artefact containing unapproved code e.g. to master or dev branches or to a RC or snapshot.

NPM

Artefacts show up on https://www.npmjs.com/package/apache<project> version page

To comply with ASF release and distributions please ensure the following:

  • The readme tab needs to include the text of the incubation disclaimer.
  • npm install apache<project> should not install an artefact containing unapproved code.

  • The latest release should not point to an artefact containing unapproved code e.g. a release candidate or snapshot.
  • Release candidates, nightlys or snapshots need to be clearly tagged.
  • The license field should display the ALv2 license.

PiPy

Artefacts need to be placed in https://pypi.org/project/apache<project>/

To comply with ASF release and distributions please ensure the following:

  • The project description should include the incubator disclaimer.
  • pip install apache<project> should not install an artefact containing unapproved code.

  • Release candidates, nightlys or snapshots need to be clearly tagged as pre-release on https://pypi.org/project/apaceh<project>/#history

  • The latest version should not point to an artefact containing unapproved code e.g. to a release candidate or snapshot
  • The meta license field should display the ALv2 license.

DistributionGuidelines (last edited 2019-02-11 20:48:42 by Justin Mclean)