Title: Publishing Releases
Notice:    Licensed to the Apache Software Foundation (ASF) under one
           or more contributor license agreements.  See the NOTICE file
           distributed with this work for additional information
           regarding copyright ownership.  The ASF licenses this file
           to you under the Apache License, Version 2.0 (the
           "License"); you may not use this file except in compliance
           with the License.  You may obtain a copy of the License at
           .
             http://www.apache.org/licenses/LICENSE-2.0
           .
           Unless required by applicable law or agreed to in writing,
           software distributed under the License is distributed on an
           "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
           KIND, either express or implied.  See the License for the
           specific language governing permissions and limitations
           under the License.

[TOC]

# Publishing Releases # {#intro}

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 ## {#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.

# The Goal of the Release Process — or — What is an Apache Release, Anyway? # {#goal}

An Apache release is a set of ** [valid](#valid) ** , ** [signed](#signed)
** , artifacts, ** [voted](#voted) ** on by the appropriate PMC and **
[distributed](#distribution) ** 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](#valid) , decides to make a release,
and designates a [release manager](#release_manager). The release manager
prepares and [signs](#signed) the proposed release materials, and offers
them up for a binding [vote](#voted) by the PMC. If the vote passes, the
release manager copies the artifacts to the [distribution
infrastructure](#distribution).

# Who Manages The Release Process? # {#release_manager}

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.

Any committer 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](#valid) release, and the project must have the
infrastructure in place to correctly [sign](#sign) the release artifacts.

# What is a Valid Release Package? # {#valid}

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 covered by the Apache License,
version 2.0. 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](http://www.apache.org/licenses/) for details on licensing and [this
FAQ](http://www.apache.org/dev/release.html) for details on release
requirements. When in doubt, contact the Foundation's Legal resources by
filing a JIRA under the 'LEGAL' project. The
[RAT](http://incubator.apache.org/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](http://www.apache.org/legal/resolved.html).

# Signing release artifacts # {#signed}

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](release-signing.html) 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 # {#voted}

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](/foundation/voting.html).

# Distribution # {#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 ## {#distribution_dist}

Each Apache TLP has a `release/`*TLP-name* directory in the **distribution**
Subversion repository at <https://dist.apache.org/repos/dist/>.
Once a release vote passes, the release manager should `svn add` the artifacts
(plus signature and hash files) into this location. Each project is responsible for
the structure of its directory. The contents of these directories are pushed to
<http://www.apache.org/dist/> by `svnpubsub`.  Note that only the most
recent release of each supported release line should be contained here; see
[here](release#when-to-archive).

## Maven Distribution ## {#distribution_maven}

See the [Publishing Maven
Releases](http://www.apache.org/dev/publishing-maven-artifacts.html) guide.

# I've Just Published A Release: Why Isn't It Available From XYZ? # {#sync-delay}

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. Mirrors have their own schedules. [Mirrors
are required](../info/how-to-mirror.html#Requirements) to check at least once
a day, but most will check for updates 2 to 4 times per day.

<a name="archivingOldReleases"></a>
# How Can I Archive An Old Release? # {#archive}

See [here](release#archived]) and [here](release#how-to-archive).

# For Legacy TLPs # {#rsync}

Older TLPs may still (through 2012 year-end) be copying release files and
signatures to `/www/www.apache.org/dist/`*TLP-name* on
`people.apache.org`.  Migrating to svnpubsub as documented above is
a painless process that brings with it a number of benefits and no drawbacks;
however, while it is supported:

### What File Permissions Should Be Set On The Release? ### {#legacy-file-permissions}

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
A
readable. In short: `-rw-rw-r--` for files, `rwxrwxr-x` for directories.

### Rsync Schedule ### {#legacy-rsync-schedule}

Rsync artifacts are deleted/[archived](#archivingOldReleases)
by deleting them from the `people.apache.org` filesystem. **Note:** such
deletions are processed once per day, whereas updated or new files are
synchronized more frequently (every two hours at present).