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