lukaszlenart commented on code in PR #1844:
URL: https://github.com/apache/struts/pull/1844#discussion_r3782771537
##########
.claude/skills/releasing-struts/release-runbook.md:
##########
@@ -0,0 +1,262 @@
+# Release Runbook
+
+The commands, in order. [`SKILL.md`](SKILL.md) holds the sequence, the gates
and the judgement;
+this file is what you type.
+
+**Provenance.** Everything marked ✔ was verified against the repository, a
completed release
+(7.3.0 / 6.11.0, August 2026), or the release manager's scripts. Everything
marked
+**⚠ unverified** is carried over from the 2017 cwiki page and has *not* been
confirmed against a
+current run — check it before relying on it, and correct this file when you do.
+
+**The scripts.** Phases 3 and 5 ship with this skill, in [`scripts/`](scripts):
+
+| Script | Phase | What it does |
+|---|---|---|
+| [`stage-assemblies.sh`](scripts/stage-assemblies.sh) | 3 | Closed staging
repo → `dist/dev`, renamed and re-hashed |
+| [`promote-dist.sh`](scripts/promote-dist.sh) | 5 | `dist/dev` →
`dist/release` |
+
+Both take `$VERSION` from the environment and refuse to run without it. They
are ports of the
+release manager's local toolbox (`~/Projects/Apache/minatour/bin/`), unchanged
in behaviour
+apart from `set -eu`, the `$VERSION` guard, tolerant hash cleanup and an
explicit svn commit
+message — each deviation is listed in the script's own header.
+
+A third script in that toolbox, `update-struts2-draft-docs.sh`, exports
Confluence into the
+retired svn production site. **It is dead and is deliberately not ported.** Do
not run it.
+
+---
+
+## Phase 1 — Prepare
+
+✔ Two lines, two releases:
+
+| Line | Branch | Build check that must pass |
+|---|---|---|
+| 7.x | `main` | `Build and Test (JDK 17)` |
+| 6.x | `support/struts-6-x-x` | `Build and Test (8)` |
+
+Both branches are protected in `.asf.yaml` and must be green before you start.
+
+```bash
+git checkout main && git pull --ff-only
+mvn clean install -DskipAssembly
+```
+
+Then:
+
+- Decide the version number from semver impact. Do not read it off the
`-SNAPSHOT`.
+- ✔ Confirm `struts-master` (currently `15`) and `struts-annotations` are
released versions, not
+ snapshots. The root pom's `<parent>` must not point at a snapshot.
+- ✔ The BOM needs no version sync. `bom/pom.xml` inherits the root version
through its
+ `<parent>` and declares members as `${project.version}`. The cwiki's
+ `struts-version.version` property no longer exists — ignore that step.
+- Review JIRA: every issue fixed since the last tag has a fix version; nothing
unresolved carries
+ this one.
+- ⚠ unverified: the cwiki's "omnibus ticket" step. The 7.3.0 and 6.11.0 runs
show no such ticket
+ — treat it as abandoned unless the PMC says otherwise.
+
+## Phase 2 — Cut
+
+✔ **Cut from a release branch, not from the line branch.** Both August 2026
releases were built
+on `release/X.Y.Z-RC1` branched off the line:
+
+```bash
+git checkout -b release/7.3.0-RC1 main # or off support/struts-6-x-x
for 6.x
+git push -u origin release/7.3.0-RC1
+```
+
+The two `[maven-release-plugin]` commits land there and **`main` is never
touched** — which is
+why the root pom still said `7.2.2-SNAPSHOT` after 7.3.0 shipped, and why the
pom is worthless
+as a source for the release number.
+
+✔ `maven-release-plugin` 3.3.1, driven interactively, on that branch:
+
+```bash
+mvn release:prepare
+```
+
+✔ No flags. `autoVersionSubmodules` is configured in the root pom, along with
the ASF parent's
+`useReleaseProfile=false`, `goals=deploy` and
`releaseProfiles=apache-release`. If you find
+yourself passing `-D` to the release plugin, the setting belongs in the pom
instead — a flag
+that has to be remembered is a flag that will be forgotten.
+
+✔ **At the SCM tag prompt, type `STRUTS_X_Y_Z`.** The plugin's default would be
+`struts2-parent-X.Y.Z`; every Struts tag in history is the underscore form,
and the GitHub
+release, the Version Notes and the site all assume it.
+
+This one cannot move into the pom: `tagNameFormat` interpolates
`@{project.version}` and has no
+string functions, so the best it could produce is `STRUTS_7.3.0`. The prompt
stays.
+
+Dry run first if you want one — add `-DdryRun=true`, then `mvn release:clean`
before the real
+run. On failure, re-run the same command: `-Dresume` defaults to true and it
picks up where it
+stopped.
+
+✔ The result is two commits on the release branch,
+`[maven-release-plugin] prepare release STRUTS_X_Y_Z` and
+`[maven-release-plugin] prepare for next development iteration`, plus the tag.
+
+```bash
+mvn release:perform
+```
+
+✔ `retryFailedDeploymentCount=10` is configured on `maven-deploy-plugin` in
the root pom, not
+passed here. It has to be in the pom to work at all: `release:perform` forks a
fresh Maven
+build, and that fork does not inherit `-D` properties from the outer
invocation — the flag the
+cwiki tells you to pass was doing nothing.
+
+⚠ unverified: the fallback for re-running `perform` elsewhere —
+`git checkout STRUTS_X_Y_Z && mvn javadoc:javadoc deploy -DperformRelease=true
-Papache-release`.
+
+**Then close the staging repository** at <https://repository.apache.org/> —
Staging Repositories
+→ select → Close. ⚠ unverified in detail, but the gate is checkable: the
artifacts must resolve
+under
Review Comment:
This supposed to be user action, inform the user to close the staging
repository and then continue
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
