This guide was generated from real release vote discussions on the Apache Incubator mailing list and reflects practical issues encountered when voting on release candidates.
This guide is intended for:
It is designed to support practical decision-making when calling a vote on a specific release candidate and responding to review feedback.
In the Incubator, a release vote is a decision on a specific release candidate. If an issue is found in the artifact under review, the correct response is to prepare a new release candidate and vote again.
This guide documents how release votes on release candidates are handled and reviewed, and how projects typically respond to review feedback.
Guidance in this document complements, but does not replace, ASF policy and legal guidance.
A release vote applies to a single, immutable artifact (for example, -rc1, -rc2).
Reviewers evaluate:
Discussion arises when there is uncertainty about what the artifact contains or how it was produced. This uncertainty typically surfaces through questions on the list during the vote.
Vote emails are expected to make verification straightforward.
Issues are raised when:
These concerns relate to review clarity and usability, not cryptographic failure.
Questions arise when:
These checks typically appear alongside other mechanical review items.
The LICENSE file is the authoritative record of bundled third-party material.
Review discussion occurs when:
LICENSECorrections are made by adjusting the artifact and, if necessary, producing a new release candidate.
NOTICE is reviewed as part of the release candidate.
Issues arise when:
In these cases, reviewers typically request removal or correction rather than addition.
Minor maintenance issues may be noted, including:
These are rarely decisive on their own but may be addressed as part of an updated release candidate.
The Work-in-Progress disclaimer communicates incubation status.
It provides context for reviewer expectations but does not replace the need to correct concrete issues in the artifact.
Licensing questions are resolved through changes to the release candidate itself.
Typical corrections include:
Resolution is confirmed by voting on the updated release candidate.
Reviewers verify signatures (.asc) and checksums for the specific release candidate under vote.
Some release votes surface guidance on mailing list mechanics, including:
These comments improve the transparency and readability of the vote thread.
Producing multiple release candidates is a normal part of incubation. Iteration reflects responsible review, not failure.