andygrove opened a new pull request, #6517:
URL: https://github.com/apache/datafusion-comet/pull/6517
## Which issue does this PR close?
There is no issue for this. It updates the release process to the order we
now follow: cut the release branch first, then find and fix regressions on it
before tagging the release candidate.
## Rationale for this change
`release_process.md` puts the pre-release audit (expression docs, benchmarks
against the previous release, scheduled CI health) before the release branch is
cut, and says "Any issues found should be addressed before creating the release
branch." The flow we now use cuts the branch first. About a week goes to
auditing the branch for regressions, with a fix PR against `main` for each one.
The next one to two weeks go to getting those fixes reviewed, merged, and
backported. The release candidate comes last.
Cutting first lets new work keep merging to `main` while the release
stabilizes, and the backporting policy already covers how fixes reach the
branch. A release takes three to four weeks this way, so the next one starts as
soon as the current one ships, which keeps us within the four-to-six-week
target in the versioning policy.
## What changes are included in this PR?
- A new **Release Cycle** section at the top of `release_process.md`, with a
diagram and a five-step summary: cut the branch, audit it for regressions
(about a week), review and backport the fixes (one to two weeks), create the RC
and hold the vote, then publish. It links to the cadence target in the
versioning policy.
- The diagram, `docs/source/_static/images/comet-release-cycle.svg`, has two
parts:
- the five steps as a loop, including the "vote fails, tag the next RC"
path
- `main` and `branch-N.M` on a shared timeline: the cut, fixes merging to
`main` and being cherry-picked to the branch with `-x`, the change log,
`N.M.0-rc1`, the vote, the `N.M.0` tag, and the next branch cut
It is 960px wide like the executor memory diagram, and has a dark palette
that follows `prefers-color-scheme`.
- The checklist is grouped into phases: cut the release branch, find and fix
regressions, create the release candidate, then the existing vote and
post-release steps. Post release gets "Start the next release".
- The branch steps (create, protect, generate docs, update both versions)
now sit under a new **Cutting the Release Branch** heading.
- "Release Preparation" moves after them as **Finding and Fixing
Regressions**. Its audit guidance is the same, except that it now targets the
release branch (for example, the benchmarks run on the branch). A new **Fix and
Backport Regressions** subsection covers fixing on `main` with the
`backport-N.M` label and backporting per `backporting.md`.
- **Creating the Release Candidate** now starts at "Check for Missing
Backports".
Otherwise no step's instructions change, and the headings that
`backporting.md` and `ci.md` link to keep their anchors.
## How are these changes tested?
Docs only.
- `prettier --check` passes on `release_process.md`.
- `./mvnw -N apache-rat:check` reports 0 unknown licenses. SVGs under
`docs/source/_static/images/` are already excluded.
- A script resolved every relative link and anchor in `release_process.md`,
including the image path and the new `versioning_policy.md#release-cadence`
link, plus the anchors that `backporting.md` and `ci.md` link to.
- The SVG is valid XML. A script measured its text with font metrics and
checked that nothing overflows a box or collides with a line or other text.
- I didn't run a local Sphinx build.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
