> 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
