You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Name the vote-passed versions explicitly; never take them positionally
`vote-passed <old_version>` published the version resolved from the tag and
deleted the version passed as the argument. 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 svn rm'd it.
Take them by name, or ask for them:
vote-passed --release 9.7.0 --old_version 9.6.0
vote-passed --release 9.7.0 --no-cleanup
vote-passed # asks for both
Anything not named is prompted for, each prompt saying what will happen to that
version. Positional arguments are now an error pointing at the named form, so
existing muscle memory fails loudly rather than quietly meaning something else.
Equal versions are refused and the release version must already be tagged.
RELEASE_VERSION and OLD_VERSION still work, with the flags winning over them.
Versions are validated by one anchored regex, shared with cleanup. A glob such as
[0-9]*.[0-9]*.[0-9]* accepts "9.7.0/", which is textually different from "9.7.0"
and so slips past the equality guard, yet SVN canonicalises the trailing slash -
cleanup would have deleted the release promote had just published. Anchoring also
rejects whitespace, v-prefixes, traversal and command characters before any of it
reaches an svn path.
The defaults behind the 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, so the
suggestion would have been the already-released 9.7.0. Order by tag creation date
instead - maven-release-plugin writes annotated tags, so that timestamp belongs to
the tag and survives fetches. The old version now comes from dist/release, the
only place that knows what this release actually replaces, with the version being
released filtered out so re-running after a partial failure cannot offer to delete
it.
Both detectors are genuinely best effort. Under `set -euo pipefail` a failed
svn ls, or a grep matching nothing - which is exactly the state after a partial
failure, when only the new release remains - aborted the release instead of
yielding no suggestion, leaving the "could not read dist/release" branch
unreachable. They now return success with empty output.
Testing the flags uncovered a bug that predates them and reached every command.
error() wrote to stdout, and resolve_version is always called as
`version=$(resolve_version ...)`, so its message was captured into the variable
instead of shown: releasing an untagged version aborted, correctly, but printed
nothing about why. info/warn/error now write to stderr. The email templates use
plain echo, so they stay on stdout and remain pipeable.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
./tools/releasing/release.sh vote-passed # asks for both
117
+
```
118
+
119
+
-**Release version** — the one being published. Defaults to the most recently *created*
120
+
`vx.y.z` tag, not the highest one: a `9.6.1` patch cut from the `9.6.0` line after `9.7.0`
121
+
has shipped is newer in time but lower in version.
122
+
-**Old version** — removed from `dist/release`, which ASF policy keeps to just the current
123
+
release. Defaults to what is published there now, excluding the version being released.
124
+
Answer `none` to skip.
125
+
126
+
`RELEASE_VERSION` and `OLD_VERSION` are honoured too; the flags win over them. Both versions
127
+
are validated as `x.y.z`, the release version must already be tagged, and the two being equal
128
+
is refused.
129
+
110
130
After the vote passes, run `vote-passed` which executes:
111
131
1.**promote** — move packages from `dist/dev` to `dist/release` in Apache SVN (prompts for SVN credentials), then release the Nexus staging repository at https://repository.apache.org and update the website download page
112
132
2.**github-release** — publish the GitHub Release for the tag, using `changes/changes-x.y.z.md` as its notes
0 commit comments