docs: rewrite the release guidelines as the current release process

[lukaszlenart]

Why

source/release-guidelines.md described a release process nobody has run in years — an Ant release target, Cactus tests, a test build posted to svn.apache.org/struts/, a release plan on wiki.apache.org. The only end-to-end description of how a release is actually made was the cwiki page Building Struts 2 — Normal release, last revised in 2017, which is still right about JIRA, the release plugin, Nexus and dist.apache.org and wrong about everything downstream:

It says	Reality
Branches develop / master	main and support/struts-6-x-x
Tag STRUTS_2_3_x	STRUTS_X_Y_Z
Export the wiki to /docs	No longer part of the site
Docker Jekyll, commit content/, svn co .../production/struts	The site builds from a PR to apache/struts-site
people.apache.org, announce.md, downloads.html	Dead host; the files are announce-YYYY.md, releases.md and download.cgi

The page

Seven phases — prepare, cut, stage, vote, promote, publish, advisories — each with a gate someone other than the release manager can verify, and the commands needed at each step. It is written to be followable on its own, so there is one document rather than two that disagree.

Content comes from the releasing-struts skill added in apache/struts#1844, which was itself verified against the 7.3.0 and 6.11.0 runs. The things most likely to surprise a release manager working from the old page:

• Releases are cut on a release/X.Y.Z-RC1 branch off the line, not on the line branch. A failed vote is a deleted branch, not a revert — and main still read 7.2.2-SNAPSHOT after 7.3.0 shipped, so the pom is worthless as a source for the release number.
• mvn release:prepare / release:perform take no command-line flags any more; autoVersionSubmodules and retryFailedDeploymentCount live in the pom.
• The SCM tag prompt still has to be answered STRUTS_X_Y_Z by hand.
• The site update is this repository's PR flow — no content/ commit, no production svn checkout.
• The [ANN] mail goes To: user@ with Cc: announce@, announcements@struts, and must be plain text from an @apache.org identity.
• The security phase is last, and the ordering GA → bulletin → advisory mails → CVE is spelled out, along with the rule that no advisory detail goes into release paperwork.

The Coding Conventions and Clarifications sections are dropped in favour of a pointer to Coding standards, which covers the same ground and is maintained. The page keeps its URL, its nav entry and the incoming link from builds.md.

Verified

bundle exec jekyll build is clean; all seven phase anchors resolve from the generated ToC, the eight alert callouts render, and every internal link (coding-standards, builds, bylaws, security, security/, download.cgi) points at a page that exists.

Follow-up — cwiki

Once this merges, these pages get replaced with pointers at
https://struts.apache.org/release-guidelines.html (stubs rather than deletions, so the inbound links and search results keep working), and the Contributors Guide links get updated:

Page	State
27832970 Building Struts 2 — Normal release	2017; superseded by this page
27834014 Building Struts 2 — Fast track release	2014; already self-marked outdated
27832965 Building Struts Annotations	2011; svn-era
27839549 Building Struts Master	2012; svn-era

Version Notes and Migration Guide pages stay on the wiki — those are per-release artifacts, not process docs.

Still needs porting, and deliberately not invented here:

• Releasing struts-master. apache/struts-master is a git repository now, so the 2012 svn instructions are stale, and the current process has not been verified by anyone recently.
• Releasing struts-annotations. Same situation.
• The milestone / RC variant (7.0.0-M1-style), which the "fast track" page half-covered.
• struts-archetypes and struts-extras — no process page was found for either; whether one ever existed is unknown.

🤖 Generated with Claude Code

[asf-ci]

Staged site is ready at https://struts.staged.apache.org/