2016/04/10 - Apache Wookie has been retired.

For more information, please explore the Attic.


This document is an overview of the release process for Apache Wookie.

Release Phases

This section summarises each phase in the release process. There are more details for each phase in the sections below.

  1. Development
    1. Analyze Open Issues
    2. Issue Fixing - ongoing - all issues should be resolved or moved
    3. Issue Validation - all resolved issues must be checked as being truly fixed and thus marker as verified
    4. Collect committer public keys
    5. Licence Audit and Legal Audit - including headers, dependencies, LICENCE and NOTICE files
  2. Release Candidate
    1. Licence Audit and Legal Audit - including headers, dependencies, LICENCE and NOTICE files
    2. Documentation – Check installation and build documentation for accuracy, create status document, create release notes
    3. Create release branch on SVN – sign binaries, permissions
    4. Test, test, test! (repeat from previous step until no problems emerge in test)
  3. Prepare for release
    1. Write the release announcement (with approval from press@)
    2. Tag the release branch
    3. Build the release files
    4. Signing of release files
  4. Vote on release
  5. Release
    1. Upload to distributions site
    2. Wait for mirroring to take place
    3. Announce the release


These steps are to be carried out in the run up to a relase. They are, in the main, an ongoing activity rather than a part of the release cycle itself.

Open Issues

A list of outstanding issues is generated from Jira. This list is posted to the project developer list with suggestions to either implement for the release or postpone for the next release. After community discussion JIRA is updated accordingly.

When deciding whether to implement an issue for this release be aware of taking on too much. It is more important to get a release out than to complete all features. Release early, release often.

Once complete this process gives a clear definition of what will be included in the release and allows timescales to be estimated.

Issue Fixing and Verification

Each issue for the release to be fixed then the fixes to be tested, reviewed and accepted.


The committers for the project need to provide public keys for the release, each person who submits a key needs to keep the private key safe. These will be included with the release in a KEYS file. The process of creating a key pair should be consistent across the committers. Apache recommend using GNU Privacy Guard to generate keys and sign the artifacts.

Committers without a code signing key should generate one - RSA 4096 bits

If committers have a DSA or RSA key of less than 2048 bits then a new one should be generated for signing releases, again using RSA 4096 bit.

For committers who already have an RSA key of 2048 bits or more some configuration of their client to avoid weaknesses are required. Instructions on how to do this can be found here.

Web of Trust

Once individuals have generated keys, opportunities should be taken (where possible) to join the Apache Web of Trust. First the keys should be uploaded to a public key server (is there a recommended one we should use?). Next key signing: if conferences are attended or events where there are other Apache developers and there are key signing parties.

There is a need to check all licenses manually, including headers in source files etc... The licenses for all libraries should be in place. LICENSE and NOTICE files need to be created. The Release Audit Tool (RAT) report is helpful in this regard.

In licenses/all_licenses.txt record the details of all dependencies; this should include not only any libraries referenced directly in ivy.xml, but also any dependencies of features, connectors and widgets. It is not, however, necessary to document licenses of secondary dependencies.

The LICENSE file should contain our license and the licenses for all dependencies underneath.
The NOTICE file contains the following text modified for our project and the notices from dependencies underneath.

Apache PRODUCT_NAME Copyright yyyy The Apache Software Foundation

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

Release Candidate

This is the first real phase of the release process.


The installation and build documentation which is included with the release needs to be checked for accuracy. Other documentation is maintained online and can be modified when required. When we announce the release it would be good to review the documentation for accuracy and usability. The status document can be generated from the issue tracker with some introduction. Release notes need to be created.

Release Tag

When we reach code freeze a tag should be created in which the release is built and signed. This will allow continued development on trunk. The tag can also be used to maintain the release, but any changes or fixes there need to be merged back into trunk. There is a detailed description here of an approach similar to this. When built and signed the tag should be considered the release candidate for testing.

Build the release candidate

The release candidate files are built from the release branch. The files to be provided are:


The final build should be tested on all supported platforms, we provide a minimal testing script for your to follow.

If any tests identify problems the community needs to decide if this is a blocker to the release or not. If not a blocker the issue should be documented, if a blocker it should be fixed and a new release candidate is built.

Prepare for release

This is where we build the actual release.

Write release announcement

The release announcement is written in cooperation with the press@ list.

Tag the release branch

The release branch is tagged with the release number.

Build release files

All release files are built from the tag. Release files are:

Signing of release files

A minimum of three committers must sign the release using their keys avilable in SVN.

Vote on the release

The community votes on the release. Since the release candidate has been thoroughly tested by the community this should be a formality. However, it is an important formality as it indicates that the project management committee have verified the legal integrity of the release.

If you are a PMC member you should not vote +1 unless you are satisfied that the software is, to the best of your knowledge, ready for release.


All there is to do now is get the release out there.

Upload to distribution site

Once you have uploaded the files to the distribution site you will need to check permissions and wait for mirroring to take place.

Announce the release

The release announcement needs to be posted to: