Name the vote-passed versions explicitly and validate them before use

[wu-sheng]

Problem

vote-passed <old_version> published the version resolved from the tag and deleted the
version passed as the argument:

cmd_vote_passed() {
    local old_version="${1:-}"     # ← the argument, and it gets svn rm'd
    version=$(resolve_version "")  # ← what actually gets released

Two versions that do opposite things, and only one of them positional — the deleted one.
Reading vote-passed 9.7.0 as "release 9.7.0" is the natural interpretation, and it would
have promoted 9.7.0 into dist/release and then immediately removed it.

Fix

Take them by name, or ask for them:

./tools/releasing/release.sh vote-passed --release 9.7.0 --old_version 9.6.0
./tools/releasing/release.sh vote-passed --release 9.7.0 --no-cleanup
./tools/releasing/release.sh vote-passed          # asks for both

Anything not named is prompted for, each prompt saying what happens to that version:

  The version being released. It must already be tagged and voted on.
  Most recently tagged: 9.7.0 (tag v9.7.0)
  Release version [9.7.0]:

  The version to remove from dist/release. ASF policy keeps only the
  current release there; older ones are served from archive.apache.org.
  Currently published in dist/release: 9.6.0
  Old version to remove [9.6.0] (or 'none' to skip):

• Positional arguments are an error, pointing at the named form — existing muscle
  memory fails loudly instead of quietly meaning something else.
• Equal versions are refused, both are validated as x.y.z, and the release version
  must already be tagged.
• RELEASE_VERSION / OLD_VERSION still work; flags win over them.

The defaults behind those prompts were wrong too

The release version came from the highest version tag, but releases are not monotonic.
A 9.6.1 patch cut from the 9.6.0 line after 9.7.0 has shipped is newer in time but
lower in version:

$ git tag -a v9.6.1 v9.6.0^{commit} -m "patch"      # tagged today
$ git tag -l 'v[0-9]*.[0-9]*.[0-9]*' --sort=-v:refname | head -1
v9.7.0                                              # ← already released

Ordered by tag creation date now — maven-release-plugin writes annotated tags, so that
timestamp belongs to the tag and survives fetches. The old version comes from
dist/release, the only place that knows what this release actually replaces, excluding
the version being released so re-running after a partial failure cannot offer to delete it.

A pre-existing bug this uncovered

error() wrote to stdout, and resolve_version is always called as
version=$(resolve_version ...). Its message was captured into the variable rather than
shown — releasing an untagged version aborted correctly but printed nothing about why, and
this reached every command, not just vote-passed.

info/warn/error now write to stderr. The email templates use plain echo, so they
stay on stdout and remain pipeable.

The old version was also unvalidated, so a typo like --old_version 9.6 would have been
handed to svn rm as a path.

Testing

Against the live repository and Apache SVN:

Case	Result
--release 9.7.0 --old_version 9.6.0	releases 9.7.0, removes 9.6.0
--old-version (kebab alias)	same
--release 9.7.0 --no-cleanup	releases 9.7.0, dist/release untouched
RELEASE_VERSION / OLD_VERSION	honoured; flags win
no arguments	both detected as defaults, confirmed by the operator
vote-passed 9.6.0	aborts, points at the named form
both versions equal	aborts: would delete the release being published
--release 9.9.9 (untagged)	aborts with a visible message — previously silent
--old_version 9.6	aborts: must look like x.y.z
--release with no value / --bogus	aborts
simulated v9.6.1 on the 9.6.0 line	suggests 9.6.1; old ordering gave 9.7.0
email announce piped	body still on stdout

🤖 Generated with Claude Code