releasing-struts

name	releasing-struts
description	Use when running or planning an Apache Struts release on any maintenance line (6.x, 7.x) - cutting the tag, staging artifacts, opening the vote, promoting, updating the site and announcing - or when asked what the next step in a release is.

Releasing Struts

Overview

A release is seven phases with a gate between each.

The process itself is published, at Release Guidelines — every phase, every command, the release policy and the one-time setup a new release manager needs. It is the source of truth, it is maintained in apache/struts-site (source/release-guidelines.md), and it is what you follow.

This skill is the agent's half of it: the judgement about ordering and when to stop, which sibling skill owns which document, and the points where a step is the release manager's to take rather than yours. release-runbook.md holds that last part.

Core principle: a phase is finished when its gate is verifiable by someone other than you. "I ran the command" is not a gate; "the URL resolves" is.

Corrections go to the site page. If a release teaches you something the guidelines get wrong, fix them in a PR to apache/struts-site. Only what is genuinely agent-specific belongs here.

The phases

#	Phase	Gate before moving on
1	Prepare	Branch green, version decided, parent poms released
2	Cut	Tag pushed, artifacts in a closed Nexus staging repo
3	Stage	Assemblies in dist/dev, Version Notes page live, [TEST] mail sent
4	Vote	72 h elapsed, three binding +1, result mail sent
5	Promote	Nexus repo released, dist/dev → dist/release, 24 h rsync waited
6	Publish	Site PR merged, GitHub release un-flagged, [ANN] mail delivered
7	Advisories	Bulletins public, CVE records filled, advisory mails sent from the CVE tool

Phase 7 only exists when the release carries a security fix, and publishing the advisory is strictly after phase 6 — see Security work is a separate clock below. Writing the bulletin is not: it is usually drafted long before the release exists, and often on its own timetable entirely.

Which skill owns which artifact

Cross-references, not copies. Do not restate what these settle:

• creating-version-notes — the Version Notes page, its Staging Repository block, the Migration Guide entry, the GitHub release notes, and the [TEST] mail. All of phase 3's paperwork.
• creating-release-vote-mail — the [VOTE] mail. All of phase 4's paperwork.
• creating-security-bulletins — the S2-XXX page, what may be disclosed and when, publication, and the advisory mails.

That last one is not a phase of this process. A bulletin gets written when the report is triaged, which may be months before a release carries the fix, and plenty of bulletins are handled with no release in flight at all. It is a skill in its own right, invoked whenever it is needed. Phase 7 is the reverse direction: if this release carries a security fix, then once phase 6 is done, go and follow that skill.

Phases 1, 2, 5 and 6 have no sibling skill — the guidelines carry those steps, and this skill carries the ordering that binds them.

Two lines, two releases

main is the 7.x line; support/struts-6-x-x is 6.x. Both are protected and both require their build to pass. A change that lands on both is two releases, each with its own tag, vote, site entry and announcement — not one release mentioned twice.

They can be cut in parallel and voted in parallel, and usually are. Keep the version numbers independent: 6.11.0 and 7.3.0 shipped together and share nothing but a date.

Neither line branch is where the release is cut. Both August 2026 releases were built on a release/X.Y.Z-RC1 branch off the line, so the [maven-release-plugin] commits never reach main. A failed vote is then a deleted branch, not a revert.

The version number is chosen at release time

The -SNAPSHOT in the pom is a placeholder, not a decision. Pick the number from the semver impact of what actually landed since the last tag, and say so out loud before cutting — the tag is the first irreversible act of the release.

The pom cannot tell you: because releases are cut on a side branch, main still read 7.2.2-SNAPSHOT after 7.3.0 had shipped.

Security work is a separate clock

Nothing about an unpublished advisory goes into the release paperwork. Not the Version Notes, not the [TEST] mail, not the [VOTE], not the commit messages, not the site entry. The tickets are neutral; that is deliberate and it is what makes the embargo survive a public release process.

The advisory follows the release, and the ordering is not negotiable:

release GA  →  bulletin unrestricted  →  advisory mails  →  CVE pushed to MITRE

A bulletin published before the fixed artifact is downloadable tells attackers what to look for and gives operators nothing to do about it.

A 6.x release containing only embargoed fixes is self-disclosing — the diff between the two tags is the vulnerability whatever the commit messages say. That is a reason to bundle it with unrelated work, or to publish the bulletins with the release, not a reason to pretend otherwise.

The cwiki release pages are retired

The wiki pages a release manager used to land on — Building Struts 2 — Normal release, Fast track release, Creating and Signing a Distribution, One time steps, Sample announcements — were retired in August 2026 and now carry nothing but a pointer to Release Guidelines. Their old content survives only in page history, where it describes a process last revised between 2013 and 2017: develop/master branches, people.apache.org, an svn checkout of the production site.

Never restore a step from that history. If something in the guidelines looks incomplete, the answer is the last release, not the last wiki revision.

Gates that are actually load-bearing

• A closed Nexus staging repo, not just a successful release:perform. Until it is closed the URL in the Version Notes resolves to nothing and every tester is blocked.
• 72 hours, and three binding +1. PMC votes are the binding ones; private@ is on the vote mail so binding voters see it.
• 24 hours after the dist move, before announcing. ASF mirroring guidance. Announcing into an unmirrored release sends everyone to a 404.
• The GitHub release stops being a prerelease at phase 6, not at phase 3. During the vote it must still be flagged, or the vote is on an artifact the world already treats as final.

Red Flags — STOP

• Cutting a tag before the version number has been stated and agreed
• A [VOTE] opened on a staging repo that is not closed, or on a link that 404s
• Announcing before the 24-hour mirror wait
• Any severity, CVE, S2-XXX or bulletin link in release paperwork
• A bulletin unrestricted before the fixed release is downloadable
• Reviving a step from the history of a retired cwiki page
• One release "covering" both maintenance lines
• Inferring the release version from the -SNAPSHOT in the pom
• Closing or releasing a Nexus staging repository yourself — that is the release manager's login

Common Mistakes

Mistake	Reality
"release:perform succeeded, so the artifacts are staged"	They are staged and open. Close the repo or nobody can fetch them.
"The vote passed, so it's released"	Nexus release, dist move and the mirror wait all come after.
"I'll announce now and fix the site after"	The announcement links the site. Merge the site PR first.
"The 6.x fix is the same change, so one announcement covers both"	Two artifacts, two downloads, two sets of affected users.
"The advisory is an announcement, so it gets [ANN] too"	[ANN] is for releases. CVE reports take the CVE tool's subject unedited.
"The pom says 7.3.1-SNAPSHOT, so this is 7.3.1"	The placeholder is not a decision. Semver impact decides.
"The process is documented in this skill"	It is documented on the site. This skill adds ordering, ownership and hand-offs.
"I found the release steps on the wiki"	Those pages are stubs now. Their history is the 2013–2017 process.