creating-release-vote-mail

Creating a Release Vote Mail

Overview

The [VOTE] mail opens the formal release vote. It is four links wrapped in frozen ASF boilerplate, around a plain-text rendering of the release's Version Notes page.

Core principle: the mail is a rendering of the page, not a second account of the release.

This is the step after creating-version-notes. That skill produces the page, the GitHub release and the [TEST] announcement; this one consumes all three. If they do not exist yet, you are in the wrong skill. releasing-struts holds the surrounding phases and what happens once the vote passes.

vote-mail-template.md is the source of truth for the artifact.

The mail is exactly these parts, in this order

1. The two-sentence opener
2. The page's Breaking changes, Deprecations and Rejected requests, where present
3. The page's issue-type sections, in page order
4. The four link lines
5. The vote boilerplate
6. The sign-off

A part not on this list is not in the mail, and one mail is produced, not two. Every section is the page's content; the opener is the only prose you write.

The pull here is toward helpfulness — an upgrade-notes section derived from the fix commits, a summary of what changed for integrators, a companion note to a subset of recipients. All of it is real work that belongs somewhere else. A vote is a judgement on the staged artifacts, and the page is what describes them.

The vote carries no security information

No severity, no CVE, no S2-XXX, no bulletin link, no attack description, no reporter or coordination detail. That disclosure happens after the vote passes and the version is released.

The restriction is on the vote, not on the audience. Routing advisory detail through private@, a Cc, an attachment or a companion mail is the same violation as putting it in the body — a second mail sent to open the vote is part of the vote. "The recipients already hold this information" is not an exemption; the vote is simply not the vehicle.