Page History

NOTE: This file is now managed in the wookie site svn. Please make edits there.

Introduction

This document is an overview of the release process for the first release of Apache Wookie. It is a live document at the moment in that it will be updated as the release process takes place. The intention is that it will become a record which can be referred to for future releases.

Release Phases

• Analyze Open Issues √
• Issue Fixing - ongoing - all issues should be resolved or moved √
• Developers create signatures - who should be included in this list? √
• Licence Audit and Legal Audit - including headers, dependencies, LICENCE and NOTICE files √
• Documentation – Check installation and build documentation for accuracy, create status document, create release notes
• Create Release branch on SVN – sign binaries, permissions 22nd Oct
• Test, test, test!
• Vote on release
• Request approval from Incubator PCM
• Upload to incubator dist
• Check permissions
• When mirroring has taken place update website and announce the release.

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 estimatedThe mailing list was used to vote on whether open issues could be moved to the next version or had to be fixed for this.

Issue Fixing

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 (Post Release and ongoing)

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.

License Audit and Legal Audit

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.

...