jamesfredley commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4521049110
### Follow-up: how this PR also fixes the "draft `7.0.7` while `7.0.6` is
being voted on" cascade
This came up offline as a longstanding pain point with the drafter, so worth
pinning it explicitly. `include-pre-releases: true` (one of the three filter
changes in this PR) is the entire fix on the drafter side.
#### Why it was broken
Our ASF release flow stages every release on GitHub with `prerelease=true`
for the duration of the 72-hour vote. The release-drafter default is
`include-pre-releases: false`, so during the vote window the in-flight release
is invisible to the action. Consequences:
- `7.1.x` and `7.0.x`: drafter would bump from the *previous* stable (e.g.
`v7.0.10`), try to draft `v7.0.11`, but `v7.0.11` already existed as the
in-vote prerelease. Either the draft never moved forward or it collided with
the in-vote tag.
- `8.0.x`: `v8.0.0-M1` is permanently `prerelease=true` (milestone
convention), so the drafter has *never* been able to see any release on
`8.0.x`. That is why no `8.0.x` draft exists today.
Net effect: there was no draft for "the next version" while a vote was
running, which is exactly the moment a maintainer wants to look at one.
#### Why it now works
With `include-pre-releases: true`, release-drafter sees prereleases when
picking the "last release". Combined with the existing `version-resolver`
(which defaults to a `patch` bump and reads `type: major / minor / patch` PR
labels), the cascade is fully automatic:
```
v7.0.11 published, no in-flight vote -> drafter maintains draft
v7.0.12
v7.0.12 staged (prerelease=true), vote open -> drafter sees v7.0.12 as
last release
-> drafter maintains draft
v7.0.13
v7.0.12 vote passes, prerelease flag dropped -> same baseline, drafter
keeps maintaining v7.0.13
v7.0.12 vote fails, prerelease tag deleted -> drafter falls back to
v7.0.11
-> draft becomes v7.0.12
again, automatically
```
Equivalent flow on `8.0.x`:
```
v8.0.0-M1 (prerelease=true, permanent) -> drafter maintains draft v8.0.0-M2
(or v8.0.0-RC1 / v8.0.0 with the
right type: label)
```
Minor caveat on milestone branches: `semver.inc('8.0.0-M1', 'patch')` is
`8.0.0` (strip prerelease, no version bump), so M1 -> M2 transitions need a PR
labeled `type: minor` or the draft tag manually renamed. Once a non-milestone
`8.0.x` release is cut, the cascade behaves the same as on `7.0.x`.
#### Where the existing `apache/grails-github-actions` next-version logic
fits
For completeness - there *is* a "calculate the next version" script in the
Apache org:
[`apache/grails-github-actions/post-release/increment_version.sh`](https://github.com/apache/grails-github-actions/blob/asf/post-release/increment_version.sh)
(`-M` major, `-m` minor, `-p` patch, with M/RC handling). It is invoked from
`release.yml`'s `close` job *after* a successful vote, and its job is to write
`${NEXT}-SNAPSHOT` into `gradle.properties` for the next dev cycle. That is a
different concern from "what version should the next GitHub Release *draft* be
tagged as", which is what `release-drafter` handles via `version-resolver`.
Both default to a patch bump, so they agree by default. If we ever want them
to disagree (e.g. cut a minor instead of a patch), we already have two
coordinated mechanisms:
- **Snapshot bump in `gradle.properties`**: override the call to
`increment_version.sh` (or pass an explicit `RELEASE_VERSION` to
`post-release`).
- **Draft tag in release-drafter**: label one of the merged PRs with `type:
minor` (or `type: major`) so `version-resolver` picks the matching bump.
There is no need to wire `increment_version.sh` into the drafter -
release-drafter already does the same computation, sourced from PR labels
instead of a hard-coded flag, which is actually closer to "intelligent enough
to figure out the next version" than a fixed `-p` invocation. The dilemma
described offline is resolved by fix #2 in the PR description; no additional
action or plugin is required.
--
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]
