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
