• Features included in the release
• Version # consensus
• Repo (git) preparation
• Testing

Packaging & Signing RC

Release Check

• Mandatory Release items
• Optional Release items

• Voting/ PMC
• Final approval to publish

• Artifacts in repo
• Docs on website
• Announcement on distribution list

Checksums and PGP signatures are valid

See the Release Signing dev documentation.

Build is successful including automated tests

The expanded source archive is expected to build and pass tests.

DISCLAIMER is correct, filenames include "incubating"

See the Podling Branding Guide.

Top-level LICENSE and NOTICE are correct for each distribution.

See the Licensing How-To, plus various pages under Legal Affairs.

All source files have license headers where appropriate.

See the ASF Source Header and Copyright Notice Policy.

The provenance of all source files is clear (ASF or software grants).

See the IP clearance section of the Mentor's guide, as well as the Releases section of the Incubator's policy page.

Dependencies licenses are ok as per http://apache.org/legal/

See ASF Legal Previously Asked Questions

Release consists of source code only, no binaries

Each Apache release must contain a source package. This package may not contain compiled components (such as "jar" files) because compiled components are not open source, even if they were built from open source.

Alternate Release process(?)

This section explains an alternate release procedure established in December 2013, as documented in the Incubator's incubation policy page. It is available only to selected podlings.

Release manager

Is this available to Geode?

Build instructions are provided, unless obvious.

Make sure that users do not have to guess how to build the project.

Each expanded source archive matches the corresponding SCM tag

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.

Need a release branch created with identical version name.

RAT report clean.

To assist license header checking, some projects use RAT -- possibly running it via Maven or another build tool.

Build task runs rat. Verify no suspect rat excludes

Change log clean.

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.

If there are copyright dates in files other than NOTICE, ensure that these are up to date.

Issue tracker clean for release version.

Make sure there are no open issues which should block the release.

Extended tests pass.

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.

Test that the release builds successfully on all target platforms.

Documentation build clean

If the documentation is built as part of the release preparation process, ensure that it built correctly

Two actions here:

• Documentation on website
• Javadoc (API) tasks

Downstream distributions build successfully.

If the project provides direct support for downstream distributors (Maven, Debian, CPAN, PyPI, etc), ensure that whatever support is provided works as intended.

Need to check Maven distribution/ repo.

Spring repo?

Binary release does not contain redundant dependency archives.

Avoid wasting bandwidth and space for the sake of mirrors, users, and other downstream consumers.