Hmm, i'm -0 to change, I dont see much benefit. That said if we move to say "we don't do branches for maven 4/maven 3" but move plugins to multimodule builds with shared+mvn3+mvn4 in a single branch and versions (maven vs plugins) are independent then it is a real pro since it enables to reduce backports and I'd move that to master/main, everything else is useless noise IMHO.
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 jeu. 8 oct. 2026 à 18:20, Gerd Aschemann <[email protected]> a écrit : > Fair questions -- here are numbers on the fork impact, since that's the > main concern. > > Across the 9 repos there are ~620 forks, but the relevant subset is much > smaller: > > - ~74% (about 465) were created BEFORE these repos moved master to the > Maven 4 > line (that switch happened in 2024, March-June). Their master is > therefore > ALREADY the Maven 3 line. Bringing upstream master back to Maven 3 puts > it on > the SAME line those forks are on -- it reduces divergence, it doesn't > create > it. They need nothing. > - That leaves ~155 forks created after the switch (Maven 4 master). Of > those, > only ~100 are active (a push in the last 12 months); the rest are > untouched. > > So the forks that could face a one-time realignment are on the order of > ~100, > not 620. And even for them: > > - The rename does not touch fork branches -- a fork keeps its branches > unchanged. > - Open PRs from forks are retargeted automatically by GitHub when the base > is > renamed (that's exactly why we rename instead of force-push) -- no > manual PR > work. > - The only manual step is for someone who keeps their fork's master in > sync with > upstream and wants to continue: rename their master to <repo>-4.x and > track the > new master. It's a one-time, documented step. > > And for the few who do keep a fork's master in sync with upstream, > realigning is > quick -- your current master (Maven 4) becomes upstream's <repo>-4.x, and > master > becomes Maven 3: > > git fetch upstream > git branch -m master <repo>-4.x # your Maven 4 line > git branch master upstream/master # the new Maven 3 default > > Open PRs move by themselves; the above is only for a long-lived local > master, and > it will be in the switch announcement too. > > On the benefit -- worth weighing honestly: it's not maintenance burden (the > branches are the same either way), it's what a casual clone or a new > contributor > lands on. The agreed direction is Maven 3 as the default line until Maven 4 > adoption has progressed; today a fresh clone of these repos lands on Maven > 4, > which is the opposite. > > Per repo, as "forks (created before the 4.x switch = Maven 3 master / > created > after = Maven 4 master / of those, active in the last 12 months)": > > - maven-compiler-plugin: 198 (156 / 42 / 26) > - maven-jar-plugin: 80 (64 / 16 / 14) > - maven-deploy-plugin: 79 (60 / 19 / 10) > - maven-clean-plugin: 61 (46 / 15 / 8) > - maven-install-plugin: 49 (39 / 10 / 6) > - maven-source-plugin: 42 (27 / 15 / 10) > - maven-filtering: 41 (26 / 15 / 11) > - maven-resources-plugin: 39 (25 / 14 / 11) > - maven-archiver: 30 (21 / 9 / 7) > - Total: 619 (464 / 155 / 103) > > Only the last number on each line ("active Maven-4-master forks") is one > that > might want the one-time realign. > > > > > > On 8. Oct 2026, at 09:30, Romain Manni-Bucau <[email protected]> > wrote: > > > > Is the proposal to force all forks to be updated for both branches ([1])? > > Is it worth it or do we expect your claude to go on all computers? > > > > [1] > > > https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch > > > > 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 jeu. 8 oct. 2026 à 09:26, Slawomir Jaranowski <[email protected]> > a > > écrit : > > > >> On Tue, 6 Oct 2026 at 10:46, 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. > >>> > >> > >> Did we estimate how many forks will be affected by it? > >> > >> > >>> > >>> 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 <+49%20173%203264070> <+49%20173%203264070> > <+49%20173%203264070> -- > >> [email protected] -- > >>> https://aschemann.net > >>> > >>> > >> > >> -- > >> Sławomir Jaranowski > >> > > -- > Gerd Aschemann (er/he) --- Veröffentlichen heißt Verändern (Carmen Thomas) > +49/173/3264070 <+49%20173%203264070> -- [email protected] -- > https://aschemann.net > >
