Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

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.