Unfortunately we couldn’t get the desired support from Infra as they had to cope with more important stuff (security issue) by today. Will give it another try tomorrow.
> On 18. Oct 2026, at 07:55, Gerd Aschemann <[email protected]> wrote: > > Good Morning, > > The preparation is done and reviewed, so I'm starting the switch now. > > I'm beginning with a single pilot, so we can validate the whole > procedure end to end before touching the rest: maven-filtering > > https://github.com/apache/maven-filtering/pull/412 > > It has only one open PR and is already released, which makes it the > lowest-risk candidate. > > For each repository the swap is: > > - rename the current default "master" (Maven 4 line) to <repo>-4.x > - rename <repo>-3.x to "master" (restored as the default branch, > coordinated with INFRA) > - a committer merges the prepared pre-staging PR so the new master > carries the repo-wide default-branch configuration (.asf.yaml, > .github, Jenkins badges) that GitHub and ASF infra only read from > the default branch > > GitHub auto-retargets the open PRs on rename, so contributors' > existing PRs are preserved. > > Two components are intentionally held back from today's batch: > maven-archiver and maven-jar-plugin, because their release votes are > not officially closed yet. They will follow in a separate, later swap > once released. > > Once the pilot looks good I'll continue with the remaining components > and report progress here. > > As of now, I have no approval for m-compiler-p and m-archiver as well as > m-jar-p have pending release votes. > Therefore, I will postpone all three until this is sorted out. > > Runbook: https://cwiki.apache.org/confluence/x/85fwGg > > Regards, > Gerd > >> On 6. Oct 2026, at 10:45, Gerd Aschemann <[email protected]> wrote: >> >> Hi all, >> >> Following up on Hervé's call to lead the Git work for maven-sources#57 >> <https://github.com/apache/maven-sources/issues/57>: a handful of >> Maven-4-specific plugins and shared components currently have their default >> master branch on the Maven 4 line, with a <repo>-3.x branch for Maven 3. >> That is the reverse of our agreed direction — the default should be Maven 3, >> with Maven 4 as a separate branch until Maven 4 adoption has progressed. >> Concretely, it avoids signalling that users moving to Maven 4.0 must also >> switch to the new (Maven 4 API) plugins; Maven 4.0 is expected to run the >> Maven 3 plugins. >> >> This originates from Hervé Boutemy (tracking issue + #maven Slack thread >> <https://the-asf.slack.com/archives/C7Q9JB404/p1789896368528809>); the full >> plan / runbook is on Confluence >> <https://cwiki.apache.org/confluence/x/85fwGg>. >> >> Scope (plugins / components only, NOT Maven core): >> >> core plugins: clean, compiler, deploy, install, resources >> packaging: jar, source >> shared: archiver, filtering >> special case: plugin-tools — no swap; master stays Maven 3 (drop the -3.x >> branch, rename the version to 3.17.0-SNAPSHOT). >> The target branch name stays master (not main); a move to main, if ever, >> should be a separate global decision, not a side effect of this. >> >> Method — rename, not force-push: >> >> rename master (Maven 4) → <repo>-4.x >> rename <repo>-3.x (Maven 3) → master >> Renaming the base branch makes GitHub retarget open PRs automatically, so >> merge bases and PR history are preserved (~45 open PRs across these repos). >> >> Impact on forks: renaming the upstream branches does not touch forks. A >> fork's master keeps the old (Maven 4) content and its default branch is >> unchanged; each fork owner realigns their own branches afterwards (e.g. >> rename their master → <repo>-4.x and track the new upstream master = Maven >> 3). Open PRs from forks keep working — GitHub retargets their base on the >> upstream rename. This is a one-time, per-fork manual step; it will be >> documented, and those of us with forks (myself included) will handle our own >> as a follow-up. >> >> Plan: >> >> Execution approach agreed with INFRA: INFRA performs the two >> protected-branch renames per repo by hand; we handle .asf.yaml, default.xml >> and README. Rehearsed on a throwaway fork first. >> One low-risk first test (maven-filtering, 1 open PR), verify, then the rest >> en bloc — in a single coordinated window, timed with the plugin maintainers >> and outside any open staging/release vote. >> Timing: from ~16 October (after Community over Code). >> Communication: to avoid noise I'll keep updates in this thread rather than >> per-repo mails — a heads-up when we start with maven-filtering, and one when >> starting the batch and when it is done. >> >> Please raise any objection — here or on maven-sources#57 >> <https://github.com/apache/maven-sources/issues/57> — before we start >> (targeting the weekend of 19 October, after the CoC@Glasgow). Feel free to >> comment on Slack or Confluence as well. >> >> Thanks, Gerd >> >> -- >> Gerd Aschemann (er/he) --- Veröffentlichen heißt Verändern (Carmen Thomas) >> +49/173/3264070 -- [email protected] -- https://aschemann.net >> > > -- > Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) > +49/173/3264070 -- [email protected] -- http://www.aschemann.net > -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- [email protected] -- http://www.aschemann.net
