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> -- [email protected] --
>> https://aschemann.net
>>>>
>>>
>>> --
>>> Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas)
>>> +49/173/3264070 <+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
>>
>>
--
Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas)
+49/173/3264070 -- [email protected] -- http://www.aschemann.net
