- Contents
- Publishing Releases (DRAFT 30 May 2010)
- The Goal of the Release Process — or — What is an Apache Release, Anyway?
- Who Manages The Release Process?
- What is a Valid Release Package?
- Signing release artifacts
- Voting to Release
- Distribution
- I've Just Published A Release: Why Isn't It Available From XYZ?
- What File Permissions Should Be Set On The Release?
- How Can I An Archive Old Release?
Contents
Publishing Releases (DRAFT 30 May 2010)
This document describes the Apache release process. Every Apache Software Foundation release must meet requirements for content, process, and publication. These requirements ensure that Apache contributors and users benefit from appropriate legal protection, and reflect the Foundation's goals of open, collaborative software development.
Intended Audience
Read this document if you are an Apache committer and you want to learn how to create and publish a release from an Apache project, or you have a general interest in the Apache release process. This document will provide you with an overview of tthe requirements and some commonly-used tools, and it will provide you with links to other pages with more details.
Help Wanted!
Help to finish this document by contributing documentation patches! If the information you seek isn't in this document, then please submit a patch once the instructure folks have answered your question.
The Goal of the Release Process — or — What is an Apache Release, Anyway?
An Apache release is a set of valid, signed, artifacts, voted on by the appropriate PMC and distributed on the ASF's official release infrastructure. All of the highlighted words in the previous sentence are critical, and are defined in the following sections.
To write the process on a grain of rice, an Apache project: complies with the software licensing requirements, decides to make a release, and designates a release manager. The release manager prepares and signs the proposed release materials, and offers them up for a binding vote by the PMC. If the vote passes, the release manager copies the artifacts to the distribution infrastructure.
Who Manages The Release Process?
The common practice at Apache is for a single individual to take responsibility for the mechanics of a release. That individual is called the 'release manager.' Release managers take care of shepherding a release from an initial community consensus to make it to final distribution.
Release managers do the work of pushing out releases. However, release managers are not ultimately responsible. The PMC in general, and the PMC chair in particular (as an officer of the Foundation) is responsible for compliance with requirements.
To publish releases to the Foundation's distribution infrastructure, you must have committer karma, but require no other special access. Thus, any committer, whether or not they are a PMC member, may serve as the manager of a release.
A release starts when the project community agrees to make a release. However, no release manager can make a valid release unless the community has taken the necessary steps to prepare in advance. The source code and build process must comply with the legal and intellectual property requirements for a valid release, and the project must have the infrastructure in place to correctly sign the release artifacts.
What is a Valid Release Package?
The Apache Software Foundation exists to create open source software. Thus, the fundamental requirement for a release is that it consist of the necessary source code to build the project. Optionally, a release may include compiled binaries for the convenience of users.
All the source code of the project must be convered by the Apache Software Licence. The license must be included in each source file. For the license to be valid, the code must have been contributed by an individual covered by an appropriate contributor license agreement, or have otherwise been licensed to the Foundation and passed through IP clearance. See this page for details on licensing and this FAQ for details on release requirements. When in doubt, contact the Foundation's Legal resources by filing a JIRA under the 'LEGAL' project. The RAT tool can assist in checking for compliance.
Many projects have dependencies on non-Apache components. For an Apache release to be valid, it may only depend on non-Apache components that have compatible licenses. For more information on third party license, see ASF Legal Previously Asked Questions.
Signing release artifacts
The files that make up an Apache release are always accompanied by cryptographic signatures. This allows users to ensure that the files have not been tampered with. The mechanics of signing depend on the project's build technology. The Apache infrastructure group strongly recommends that projects set up automated infrastructure to sign the files, as otherwise the process is painful. Generally, projects set up their build system so that the same process that creates the files for a release also signs them.
The process of setting up to sign the code is somewhat complicated, and it is described on the release signing page. If you plan to serve as a release manager, you should generate a key and publish it well in advance of creating a release.
Voting to Release
A binding vote of the PMC is the critical gating step in the release process. Without such a vote, the release is just a set of files prepared by an individual. After such a vote, it is a formal offering of the ASF, backed by the 'full faith and credit' of the Foundation. For more information on the voting process, see the voting policy.
Distribution
The Apache infrastructure must be the primary source for all artifacts officially released by the ASF.
The Apache Infrastructure team maintains the Apache release
distribution infrastructure. This infrastructure has two parts: the mirrored directories on
www.apache.org and the Maven repository on repository.apache.org.
www.apache.org
Each project at Apache has a directory under
/www/www.apache.org/dist. Once a release vote
passes, the release manager copies the artifacts (and signature and hash
files) into the project's directory. Each project is responsible
for the structure of its directory. Once the files are on people.apache.org,
an automated process copies them to www.apache.org.
Note that there is always some delay in the synchronization process.
Maven Distribution
See the Publishing Maven Releases guide.
I've Just Published A Release: Why Isn't It Available From XYZ?
Apache uses mirroring both internally and externally. This process runs to a schedule.
First the files on people.apache.org are mirrored to www.apache.org,
and then the external mirrors pick up the files from www.apache.org.
It may take up to 24 hours or more for a newly published release to be sync'd to all mirrors.
Note: file deletions from www.apache.org are processed once per day,
whereas updated or new files are synchronised more frequently (every two hours at present).
External mirrors have their own schedules.
Mirrors are required to check at least once a day,
but most will check for updates 2 to 4 times per day.
What File Permissions Should Be Set On The Release?
The release should be group readable and writable. The group should be set to the appropriate group
for your project. The release should be world readable. In short: -rw-rw-r--.
How Can I An Archive Old Release?
All releases are sync'd automatically to the archives. To archive a release, just remove the file from the main servers.
