This guide is distilled from real Incubator mailing list discussions about release votes and distribution corrections. It focuses only on the concrete issues and resolutions that appeared in those conversations.

Who This Guide Is For

This guide is intended for:

• Project proposers
• Podling PPMCs
• Incubator mentors
• IPMC members

These checks focus on preventing confusion about what an Apache release is and identifying and resolving distribution issues that commonly arise during release votes.

1. “Official release” vs “things that look like releases”

A recurring problem is publishing or presenting artifacts in a way that implies an official release exists before the release vote has passed.

What reviewers pushed back on included:

• A versioned “release” is being made visible on GitHub (or similar) before the vote is completed.
• Unapproved or unreleased artifacts are available to the public, searchable in project-hosted repos.
• Nightly builds or developer builds are being presented alongside releases without a clear separation.

Common correction pattern:

• Remove or hide anything that is badged as a release version until the vote passes.
• Make any non-release output (nightlies/dev builds) clearly labelled and separated from releases.
• Ensure public repositories do not imply “this is an ASF release” when it is not.

2. Distribution surfaces that trigger scrutiny

The discussions repeatedly focused on non-source distribution surfaces, including:

• container images,
• package registries (language ecosystems),
• project-hosted repositories that users can browse or search,
• website download pages and “where users are pointed”.

The key concern was not that these surfaces exist, but whether they:

• contain unapproved content, or
• create user confusion about what constitutes an official Apache release.

3. Category X and third-party code leakage into artifacts

The strongest recurring compliance theme was Category X and related third-party licensing concerns appearing inside distributed artifacts, especially convenience binaries and developer-facing outputs.

The practical focus in the discussions was:

• identifying where Category X material is bundled,
• preventing it from appearing in official release artifacts,
• and making the status of any non-release artifacts unambiguous.

4. Release candidate hygiene: LICENSE, NOTICE, DISCLAIMER, headers

Release votes surfaced concrete, repeatable issues inside source artifacts, including:

• LICENSE missing mention of included third-party code,
• NOTICE missing required content (including missing URLs),
• files missing ASF headers (with emphasis on determining whether they are third-party files),
• checking for unexpected binary files,
• ensuring a DISCLAIMER exists for an incubating release.

Resolution pattern:

• Treat these as “fix then reroll” issues, not “explain away” issues.
• For missing headers, explicitly determine whether a file is third-party (and therefore should not be edited to add ASF headers) or project-owned (and therefore should carry appropriate headers).

5. “Incubating” requirements during incubation

During release review, reviewers ensured that the incubating status was reflected correctly in release materials while the project was still in incubation. This surfaced as a hard stop when the release materials did not correctly reflect the incubating status in the release metadata.

6. Signatures, checksums, KEYS, and post-vote moves

The release vote discussion included practical handling of:

• signature and checksum expectations,
• KEYS presence and discoverability,
• moving artifacts between areas once a vote passes,
• renaming directories as part of the move.

A key operational point was raised:

• Renaming or moving the release directory does not change artifact hashes or signatures, and can be handled as part of the post-vote process when done correctly.

7. How -1s were used and resolved

The discussions show a consistent pattern:

• -1s were triggered by concrete compliance issues, not subjective preferences,
• the expectation was correction (removing premature “release” presentation, fixing NOTICE/LICENSE/header issues, rerolling when needed),
• votes progressed once issues were addressed, not merely argued.

The practical lesson is that compliance concerns are treated as blockers when they affect:

• correctness of release contents (LICENSE, NOTICE, headers, incubating status),
• trust in what constitutes an Apache release,
• and distribution channels that users will interpret as official.

Key Takeaways

• Avoid presenting anything as an Apache release before the vote passes
• Ensure distribution surfaces do not imply unapproved or unofficial releases
• Keep Category X and incompatible third-party material out of release artifacts
• Treat LICENSE, NOTICE, headers, and DISCLAIMER issues as fix-and-reroll items
• Reflect incubating status correctly in all release materials
• Handle signatures, KEYS, and post-vote artifact moves carefully and transparently
• Resolve -1s by correcting compliance issues, not by explanation alone