THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Draft release verification checklist, created in response to http://s.apache.org/awz.
Release manifest usage proposal
Moved to http://incubator.apache.org/guides/release.html.
Release manifest example
Moved to http://incubator.apache.org/guides/release_manifest.txt.
Optional release checklist items
Projects may wish to augment the default checklist in the release manifest with their own custom items. Here are some suggestions.
(This page could potentially supplant http://incubator.apache.org/guides/releasemanagement.html as a repository for best practice tips.)
Build instructions are provided, unless obvious.
| indent |
|---|
Make sure that users do not have to guess how to build the project. |
Each expanded source archive matches the corresponding SCM tag.
| indent |
|---|
It is important that any release can be reproduced from the source at any time in the future. Apache releases have long active lives and are permanently archived. It may be necessary (for example, for legal reasons) to provide a new release that is a slight alteration of a previous release. Release managers owe it to those who come afterwards to use build processes that are reproducible. |
RAT report clean.
| indent |
|---|
To assist license header checking, some projects use RAT -- possibly running it via Maven or another build tool. |
Change log clean.
| indent |
|---|
If the project provides release notes, such as in a CHANGES file, make sure that the file is up-to-date. |
All copyright dates current.
| indent |
|---|
If there are copyright dates in files other than NOTICE, ensure that these are up to date. |
Issue tracker clean for release version.
| indent |
|---|
Make sure there are no open issues which should block the release. |
Extended tests pass.
| indent |
|---|
Some projects may have an optional set of tests which are more expensive to run. Just before a release is as good a time as any to see whether they pass. |
Build succeeds on platforms X, Y, Z.
| indent |
|---|
Test that the release builds successfully on all target platforms. |
Documentation build clean.
| indent |
|---|
If the documentation is built as part of the release preparation process, ensure that it built correctly. |
Downstream distributions build successfully.
| indent |
|---|
If the project provides direct support for downstream distributors (Maven, Debian, CPAN, PyPI, etc), ensure that whatever support is provided works as intended. |
Binary release does not contain redundant dependency archives.
| indent |
|---|
Avoid wasting bandwidth and space for the sake of mirrors, users, and other downstream consumers. |