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
- 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 estimated.
Issue Fixing
Each issue for the release to be fixed then the fixes to be tested, reviewed and accepted.
Signatures
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.
| Code Block |
|---|
Apache PRODUCT_NAME Copyright yyyy The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). |
Documentation
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 including the standard incubator disclaimer.
Release Branch
When we reach code freeze a branch should be created in which the release is built and signed. This will allow continued development on trunk. The branch 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 branch should be considered the release candidate for testing.
Testing
The final build should be tested on all supported platforms. The signing of the release needs to be checked too.