• Releases FAQ
  • Contents
• Release Questions
  • What is a release?
  • How do the Types of Apache Software Distribution Differ?
  • Where Can I Find ASF Releases?
• Release Management Questions
  • What Must Every ASF Release Contain?
  • What Are The Key Points of ASF Mirroring Policy?
  • How Should Releases Be Announced?
  • Which Directory For What Build?
  • How Is An Old Release Moved To The Archives?
  • When Should An Old Release Be Archived?
  • Is There A Guide To Best Practice?
• Release Licensing Questions
  • Which Files Must Contain An ASF License Text?
  • Is A Full Copy Of The License Required In Each Source File?
  • Where Is The Right Place For Attribution Notices?
  • What Content Is Appropriate For the NOTICE file?
  • Is a NOTICE File Required For Pure ASF Code?
  • If A Distribution Contains Code Under Several Licenses, Should It Contain Several License Files?
  • Can I Distribute A Raw Artifact?

Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. How you label the package is a secondary issue, described below.

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.

The Apache Software Foundation produces open source software. All releases are in the form of the source materials needed to make changes to the software being released. In some cases, binary/bytecode packages are also produced as a convenience to users that might not have the appropriate tools to build a compiled version of the source. In all such cases, the binary/bytecode package must have the same version number as the source release and may only add binary/bytecode files that are the result of compiling that version of the source code release.

• Test Packages are not Apache releases. All releases require due process and official approval. Test packages are for testing ongoing development and should only be discussed on the project development lists.
  • Nightly Builds are simply built from the Subversion trunk, usually once a day. These packages are intended for regular testing of the build process and to give automated testers a common build for regression testing. They are not intended for use by the general public.
  • Release Candidates are packages that have been proposed for approval as a release but have not yet been approved by the project. These packages are intended for developers (and users who follow the development discussions) to test and report back to the project regarding their opinions on the package quality compared to prior releases. Many release candidates are possible prior to a release approval. Users that are not interested in development testing should wait until a release is formally approved.
• Releases are packages that have been approved for general public release, with varying degrees of caveat regarding their perceived quality or potential for change. Releases that are intended for everyday usage by non-developers are usually referred to as "stable" or "general availability (GA)" releases. Releases that are believed to be usable by testers and developers outside the project, but perhaps not yet stable in terms of features or functionality, are usually referred to as "beta" or "unstable". Releases that only represent a project milestone and are intended only for bleeding-edge developers working outside the project are called "alpha".

All current Apache releases are distributed from the main www.apache.org site's "dist" subdirectory, where they are picked up by mirrors worldwide for disribution to the general public. These releases are automatically copied to the archives and remain present on archive.apache.org even after they have been removed from the current dist directories. So, if you are looking for an old Apache release that is no longer on the mirrors, or need to refer to a permanent location (such as for legal notices), then use a link to the archives.

Every ASF release must comply with ASF licensing policy. This requirement is of utmost importance and an audit should be performed before any full release is created. In particular, every artifact distributed must contain appropriate LICENSE and NOTICE files. More information can be found in the foundation website and in the release licensing FAQ

Apache Committers,

If you are responsible for posting software for public download, please be sure to read and follow the policy listed at:
Apache Mirroring Information

Some key points in this policy:

1. Software should not be distributed from project websites. Current releases should be mirrored by placing them under www.apache.org/dist/.

2. Older releases should go under archive.apache.org/dist/. Once a release is placed under www.apache.org/dist/ it will automatically be copied over to archive.apache.org and held there permanently, even after it is deleted from www.apache.org. If you currently have older releases on your project website, you can manually copy them to archive.apache.org/dist/.

3. Do not point downloaders directly at the www.apache.org/dist/ directories. Point to the mirrors using one of the techniques discussed on the above web page.

If you need assistance in implementing URL redirection to direct downloaders to the new locations, or if you need any other help in implementing this policy, please contact the infrastructure@apache.org mailing list.

By following this policy, we will make the most efficient use of our resources and provide better service to our users.

It is important that people are informed about the availability of new releases. At the very least, emails should be sent out announcing this to all appropriate mailing lists. Many top level projects have announcement lists for this purpose. There is also an ASF-wide announcement list which is suitable.

Please note that you can not post the ASF-wide announcement list without the usage of "apache.org" mail address. Also, please make sure that you have put 3-5 lines blurb for the project. (because most of the subscribers to announce.AT.apache.DOT.org list would not know what is XX-Project, generally speaking)

It is recommended that an SHA-1 OpenPGP compatible signature is added to the announcement mail. Please ensure that your public key has been already uploaded to famous pgp sites (e.g. http://pgp.mit.edu/). This key should either be the one used to sign the release or one that is cross-signed by that key.

/www.apache.org/dist is automatically archived. Therefore, a copy of an official release will already exist in the archives. To move a release to the archives, just delete the copy in /www.apache.org/dist. Remember to update any links from the download page.

Releases which have been superceded should be archived once they are unlikely to be downloaded frequently. This may mean retaining an end-of-line release for each precedent major version even after newer releases of later major versions have been archived.

See the Incubator release management guide.

Every source file must contain the appropriate ASF License text.

In short, only one copy of the license is needed per distribution. This full license file should be placed at the root of the distribution in a file named LICENSE. For software developed at the ASF, each source file need only contain the boilerplate notice.

The new license allows for a NOTICE file that contains such attribution notices (including the Apache attribution notice). Read this.

Any attribution notices contained within existing source files should be moved into the file. The NOTICE file must included within the distributed next to the LICENSE file.

Ensure that the standard ASF attribution notice is contained in any new NOTICE file created.

Read this.

Only mandatory information required by the product's software licenses. Not suitable for normal documentation.

Yes! The NOTICE file must contain an attribute for the ASF. The standard ASF attribution is given below:

	This product includes software developed by
	The Apache Software Foundation (http://www.apache.org/).
    	

No - all license information should be contained in the LICENSE file.

When a distribution contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file.

Here is an example.

ASF distributions typically contain additional material together with the artifacts. This material may include documentation concerning the release but must contain LICENSE and NOTICE files.

Raw artifacts may be distributed if they contain LICENSE and NOTICE files. For example, the java artifact format is based on a compressed directory structure and those projects wishing to distribute raw jars place LICENSE and NOTICE files in the META-INF directory within the jar.