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.

Who This Guide Is For

This guide is intended for:

  • Podling PPMCs
  • Release managers
  • Incubator mentors
  • IPMC members

It is designed to support practical decision-making when calling a vote on a specific release candidate and responding to review feedback.

Unifying Principle

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.

Purpose

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.

1. Release Votes Are Votes on a Concrete Artifact

A release vote applies to a single, immutable artifact (for example, -rc1, -rc2).

Reviewers evaluate:

  • the staged source artifact
  • the contents of that artifact
  • the accompanying signatures and checksums

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.

2. Download Links and KEYS Must Be Clear

Vote emails are expected to make verification straightforward.

Issues are raised when:

  • KEYS are missing or in an incorrect place
  • signatures or checksums links are misisng
  • reviewers are unsure whether they are verifying the intended artifact

These concerns relate to review clarity and usability, not cryptographic failure.

3. Artifact Naming and Incubation Markers Are Checked

Questions arise when:

  • required incubation markers are missing or unclear
  • artifact names do not align with Incubator expectations

These checks typically appear alongside other mechanical review items.

4. LICENSE Must Reflect What Is Bundled

The LICENSE file is the authoritative record of bundled third-party material.

Review discussion occurs when:

  • third-party material appears in the artifact but is not clearly reflected in LICENSE
  • it is unclear whether the code is project-owned or third-party
  • bundled code is indistinguishable from project code
  • third-party headers are missing or replaced
  • files are shipped without clear provenance

Corrections are made by adjusting the artifact and, if necessary, producing a new release candidate.

5. NOTICE Is Reviewed for Correctness, Not Volume

NOTICE is reviewed as part of the release candidate.

Issues arise when:

  • NOTICE includes large amounts of dependency information
  • content appears informational rather than required
  • entries lack a clear justification

In these cases, reviewers typically request removal or correction rather than addition.

6. NOTICE Housekeeping May Be Raised

Minor maintenance issues may be noted, including:

  • outdated years
  • formatting inconsistencies

These are rarely decisive on their own but may be addressed as part of an updated release candidate.

7. The Work-in-Progress Disclaimer Provides Context

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.

8. Licensing Issues Are Resolved by Updating the RC

Licensing questions are resolved through changes to the release candidate itself.

Typical corrections include:

  • modifying the contents of the source artifact
  • updating LICENSE or NOTICE
  • restoring third-party headers

Resolution is confirmed by voting on the updated release candidate.

9. Verification Applies to the RC

Reviewers verify signatures (.asc) and checksums for the specific release candidate under vote.

10. Vote-Thread Hygiene Sometimes Matters

Some release votes surface guidance on mailing list mechanics, including:

  • how to handle withdrawn votes
  • how to post final vote results clearly

These comments improve the transparency and readability of the vote thread.

11. Iteration Is a Normal Outcome

Producing multiple release candidates is a normal part of incubation. Iteration reflects responsible review, not failure.

12. Key Takeaways for PPMCs, Mentors, and the IPMC

  • Release votes apply to a specific release candidate
  • Clear links and verification information reduce friction
  • LICENSE must accurately reflect bundled content
  • NOTICE should be correct and minimal
  • The Work-in-Progress disclaimer provides context, not cover
  • Licensing issues are resolved by updating the artifact
  • Producing a new RC is a normal and healthy outcome
  • No labels