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 -- [email protected] -- https://aschemann.net
> 

--
Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas)
+49/173/3264070 -- [email protected] -- http://www.aschemann.net

Reply via email to