Issue is that you impact contributors and not really solve the underlying issue. From my window it is a quick and dirty workaround with contributors impact.
Nothing not doable but think skipping it is worth it and solving the actually issue we are already facing would benefit the project and community rather than a task for nothing. 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 sam. 10 oct. 2026, 01:04, Gerd Aschemann <[email protected]> a écrit : > > i'm -0 to change ... if we move to ... shared+mvn3+mvn4 in a single > branch > > and versions are independent then it is a real pro > > Thanks Romain -- I think we agree on more than it looks, we're just talking > about two different things. > > The single-branch / multimodule idea (shared + mvn3 + mvn4 in one branch, > independent versions) is a real restructuring with its own trade-offs, and > it deserves its own discussion. It is orthogonal to this change: switching > the default branch back to Maven 3 does not preclude it. If the project > later > decides to unify, nothing here is in the way -- the branches still exist, > the > default just points at the Maven 3 line in the meantime. > > What this move does is deliberately narrow and reversible: it only corrects > which line a fresh clone and a new contributor land on -- back to Maven 3, > the agreed default situation while Maven 4 adoption ramps up. It adds no > branches and no maintenance; the same two lines exist either way. Today a > fresh clone of these repos lands on Maven 4, which is the opposite of what > we agreed. > > So I would keep the two separate: do the small correction now (low-risk, > open PRs retarget automatically, and it is a one-time step only for the few > forks that actively track master), and if there is appetite for the > unification, let's open a dedicated thread for it -- I am glad to help work > that through. > > > On 9. Oct 2026, at 08:46, Romain Manni-Bucau <[email protected]> > wrote: > > > > Just to correct a bit your statement Hervé > > > >> here is no rush to create Maven 4 plugins: Maven 4 plugins is a work for > > future, a target situation in a few years. > > > > There is from the external community because of the stable API which is > an > > insanely positive move - even know some writers who will not care to drop > > maven 3 support due to that hell (resolver hurted a lot by the past and > > costed a lot). > > So while I understand the statement I don't think it is that accurate, in > > particular cause maven 4 work is no more focused on the API. > > > > So while we make our plugins compatible with both, potentially in a > single > > branch, there is no need to do something special and it simplifies the > > maintenance for everybody so think we missed the goal there. > > > > 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 ven. 9 oct. 2026 à 01:43, Hervé Boutemy <[email protected]> a > écrit : > > > >> there is an important aspect: > >> we need to clarify that Maven 3 plugins are still the normal situation > >> even with Maven 4 out. > >> > >> There is no rush to create Maven 4 plugins: Maven 4 plugins is a work > for > >> future, a target situation in a few years. > >> > >> This message is not only for our Maven-team maintained plugins but also > >> all plugin maintainers from the community. > >> > >> Our users community is huge, so is our plugin maintainers community: > they > >> need time to test, learn, transition. > >> > >> > >> Gerd shares detailed plan before doing, instead of doing, creating a bad > >> situation, then having live with it. > >> Please let him fix the too aggressive move that was done: it does not > >> break anything, and he's doing the work to fix the situation. > >> > >> > >> Remember, the plan is: > >> for now, we release Maven 4.0 that runs Maven 3 plugins. > >> Maven 4 plugins are an exception, for example for Java Module > improvement, > >> where the complexity adds a real value. > >> This is what provides a smooth transition: > >> - for Maven users > >> - and for plugins maintainers (at Maven and in the community) > >> > >> Once Maven 4.0 is released and we have good feedback that Maven 4 works > >> well, we'll have time to plan wider plugins move. > >> > >> Let's avoid existing plugin maintainers confusion from Maven 4 > existence: > >> new plugin API is a long term plan that will happen after a few years. > >> Maven 3 plugins are there to strive for years, as simple as today. > >> > >> Trying to go faster is counter productive. > >> > >> > >> Thank you Gerd > >> > >> Hervé > >> > >> > >> On 2026/10/08 16:30:10 Romain Manni-Bucau wrote: > >>> 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> > >>>> <+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> <+49%20173%203264070> -- > >> [email protected] -- > >>>> https://aschemann.net > >>>> > >>>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > -- > Gerd Aschemann (er/he) --- Veröffentlichen heißt Verändern (Carmen Thomas) > +49/173/3264070 -- [email protected] -- https://aschemann.net > >
