Hi Gerd, Lazy consensus for such things would have still need a more formal vote to highlight attention IMHO (ack it doesn't require a formal binding count but lazy consensus are using votes too as a good practise when impact is global like that).
Yep can start a thread for maven3/4 plugin dev practise but potentially will make this change a lot of noise for nothing so hope we would have decided before :(. 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 lun. 19 oct. 2026 à 10:08, Gerd Aschemann <[email protected]> a écrit : > Hi Romain, > > Thanks for staying engaged -- let me separate two things, because I think > we are partly talking about different ones. > > 1) What was actually done here > > This was a narrow, reversible step: restoring the default branch to the > Maven 3 line (with Maven 4 on a <repo>-4.x branch) for the nine > plugins/components that had it the other way round. It was a rename, not a > force-push -- it changed no code and no release, and it can be undone. > > On process and timing, just so it is on record that this was neither > rushed nor a surprise: > > - I announced it on dev@ on 6 October, explicitly asking for > objections "before we start (targeting the weekend of 19 October)": > https://lists.apache.org/thread/zg052t20fww3ghzhc9mqyh969c1661z5 > - That was ~12 days of public notice, and I confirmed the 18 October > date several times afterwards (here and in #maven). > - On 10 October, in this thread, Martin -- who shares your > reservations -- wrote that the work was "ready to go, just giving a > chance for feedbacks before," and named 18 October: > https://lists.apache.org/thread/1y5xod6qc0wxljh4lvk3wxcgpry0h1j0 > > The concerns that were raised were taken seriously, not ignored. The main > one -- the fork and contributor impact (Slawomir and you, 8 October) -- I > answered the same day with concrete numbers: of the ~620 forks across the > nine repos, about 74% were created before these repos moved their default > to the Maven 4 line in 2024, so their master is already Maven 3 content and > is unaffected; for the rest the realignment is a documented, one-time step. > > On "there is no strong agreement": procedurally this implemented a > direction we had already agreed, so it ran as lazy consensus. In the thread > Hervé (who initiated it) and Guillaume were for it; Martin explicitly did > not oppose and called it ready to go; Sylwester said it made sense; > Slawomir stayed skeptical on-list but did not oppose -- he reviewed and > approved the preparation PRs; and you were -0. No -1 was raised in those > twelve days. A concrete technical objection is always worth discussing -- > but a -0 and a preference for the status quo, after that notice period, did > not seem like a reason to leave prepared, reviewed and release-coordinated > work hanging indefinitely. > > We also kept the one hard condition agreed up front: no swap while a > component release was in progress. That is exactly why maven-archiver and > maven-jar-plugin were held back until their releases were out. > > 2) Your actual point: the M3/M4 strategy > > This I do not want to brush aside -- it is the more important question. > You are right that the broader "how" (your multimodule shared+mvn3+mvn4 > single-branch idea, with plugin versions independent of Maven) is not > converged, and this branch change did not decide it. It was not meant to. > It only aligned the default-branch direction with what we had already said > we wanted; it locks us into nothing, and if the project later converges on > the single-branch model, the branches can be reorganised again. > > That discussion deserves its own space rather than being settled as a side > effect of a branch rename, in either direction. Would you be willing to > start a separate [DISCUSS] thread laying out the multimodule proposal > concretely? I will gladly help give it real attention. > > Regards, > Gerd > > > On 18. Oct 2026, at 23:31, Romain Manni-Bucau <[email protected]> > wrote: > > > > @Gerd it was reported, this thread just showed back the same resistance > for > > the same reason (~ a too late momentum and only partial solution to the > > problems we do face today). From my window the question is not "why > trying > > to stop" but more "why not trying to move forward facing our actual > > issues". We got backward and not forward right now. That M4 should be M3 > > compatible is absolutely clear, the how is totally undefined - guess it > was > > assumed to use the M3 line but it is actually not discussed and pretty > sure > > nor converged yet. > > > > 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 à 22:33, Gerd Aschemann <[email protected]> a > écrit : > > > >> 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 <+49%20173%203264070> <+49%20173%203264070> -- > [email protected] -- > >> https://aschemann.net > >>>> > >>> > >>> -- > >>> Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) > >>> +49/173/3264070 <+49%20173%203264070> <+49%20173%203264070> -- > [email protected] -- > >> http://www.aschemann.net > >>> > >> > >> -- > >> Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) > >> +49/173/3264070 <+49%20173%203264070> <+49%20173%203264070> -- > [email protected] -- > >> http://www.aschemann.net > >> > >> > > -- > Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) > +49/173/3264070 <+49%20173%203264070> -- [email protected] -- > http://www.aschemann.net > >
