To be honest, it is a little bit frustrating if you prepare such a task (spending several hours if not a day or more, even with LLM support) and ask several times for heavy objections and no one stands up against the switch until the very last moment when the ball has started to roll.
I have seen the misc. opinions, some people didn’t like it, others wanted to go ahead. No one had a real strong argument, or at least I couldn’t detect it. There was plenty of time to stop the endeavour in the last weeks. Why come up with a request for consensus when it was not reached during the time for discussion? Will there ever be consensus? Anyone could have come up with a call for a formal vote. No-one did! The switch has benefits and drawbacks. By my understanding there was a clear decision to make visible that M3 and M3-compatibility of M4 should be the main line. So why not make this clear by switching back the master branches of the components which had already (and obviously too early) switched? — Gerd Aschemann [email protected] +49 173 32 64 070 https://aschemann.net > On 18. Oct 2026, at 11:15, Romain Manni-Bucau <[email protected]> wrote: > > There doesn't seems a strong agreement on that so maybe the status quo > until reach is saner no? > > > Romain Manni-Bucau > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | > Old > Blog <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> > Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact via > linkedin) > > Le dim. 18 oct. 2026, 07:55, Gerd Aschemann <[email protected]> a écrit : > >> 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
