Estimated Reading Time:

What goes into an ASF release

One of the goals of incubation is to teach podling communities how to build ASF-compliant releases. As part of the learning process, the podling community needs to be fully engaged in the release review process. A podling community should begin to familiarize itself with the ASF policies for releases. Those policies can be found at

Releases are always produced by an Apache PMC, and for podlings, this PMC is the IPMC. This is why it is mandatory to have at least 3 positive +1 votes from IPMC members. Usually, your mentors (who are also IPMC members) will vote on your releases, but if needed, other IPMC members will as well. IPMC members will check for compliance with the ASF policies and with Incubator policies.

Anybody reviewing your releases will explain what they checked and what they found. They will also rate the severity of any issues. Some issues may be blockers. Others issues may be resolved in later releases. Those voting on the release will base their votes on this information.

If you do not understand the feedback you receive, or if you believe that it is misguided, please say so! We are all learning, and discussion is an important part of open source development.

Requesting feedback on interim non-ASF releases

When existing active communities enter the ASF via incubation, they may already have an established release rhythm. It may not be possible to conform to ASF release policies quickly enough to maintain that release rhythm. We want to welcome projects with active communities. To smooth this process, projects may need to make a few non-ASF releases after incubation begins.

A non-ASF release may or may not be staged on ASF infrastructure for a vote, but it is distributed via non-ASF infrastructure, and is either not linked from a podling’s website, or is linked but clearly marked as a non-ASF release.

Podlings can use non-ASF releases as an opportunity to find ASF policy violations and begin resolving them. Podlings can request feedback by starting a "[DISCUSS]" thread on Podlings can decide whether they prefer a "[DISCUSS]" thread or a "[VOTE]" thread. Only a release which passes a vote by members of the IPMC is an official ASF release.

Discussion should give podlings feedback on what they would need to do to bring their release in line with the requirements of an official ASF release. Podlings will be responsible for capturing feedback in work items for their project. Feedback provided in a discussion thread will not block a non-ASF release. But the ASF will not take on legal liability for these releases. A podling will need to successfully make several ASF releases before it can graduate from the incubator.

Asking for feedback for non-ASF releases is not obligatory. It is one of the services that the Apache Incubator offers our podling communities.

Podling Constraints

The Incubator policies applies two additional constraints to podlings for their releases. They are repeated here for clarity only. - Release artifacts must include incubating in the final file name - Release artifacts must include one of two disclaimers

For a podling to receive full permission from the IPMC to execute the release, the release vote must be held on the incubator general list and pass based on the standard Package Release voting rules. Only Incubator PMC votes are binding, but everyone is encouraged to vote.

The Incubator PMC expects the source releases to be staged on$podlingName so that they can easily be moved to the release location via svn mv.

Choice of Disclaimers

When making a release, a podling has a choice of using one of two disclaimers, the standard disclaimer or the work in progress disclaimer.

If it is your first release, it is recommended that you use the work in progress DISCLAIMER. This disclaimer allows you to list any non-compliance with ASF policy and IPMC members are still be able to give your release a +1 vote. Think of it as training wheels for your release.

Here is a minimal set of requirements, when using the work in progress disclaimer, a podlings release must abide by:

  • Include the word incubating in the release file name.

  • Include an ASF LICENSE and NOTICE file.

  • Have valid checksums or signatures.

  • Be placed in the correct place on the ASF’s infrastructure.

  • Have a KEYS file to validate the release.

Other issues, such as:

  • Missing ASF headers.

  • Missing license information.

  • Included unexpected binary code.

  • Including code of unknown origin.

Will be allowed if the issue is listed in the disclaimer or added to the disclaimer shortly after the release is made.

Any releases using the work in progress disclaimer must still be legal and follow the terms of any 3rd party licenses, even if they are not compatible with the Apache license.

Please carefully read this Legal JIRA for more details on what the IPMC and legal expectations are.

By the time you graduate, all issues listed in the disclaimer need to have been corrected, and you must use the standard disclaimer text.

If a podling chooses uses the standards disclaimer, then the release must comply with all ASF policies.