Hi Gerd, Thanks for driving this. Could we apply the same swap to maven-plugin-testing, so the harness follows the plugins it is used to test?
Today it is the odd one out: - master (the default branch) holds only a README saying the harness was merged into Maven core. The Maven 4 harness now lives in apache/maven, under impl/maven-testing. - maven-plugin-testing-3.x holds the Maven 3 harness (3.5.1 released, 3.5.2-SNAPSHOT in progress). Every Maven 3 plugin, ours and MojoHaus, tests against it, and that is where the fixes land. So anyone who opens the repository, forks it or points a tool at it lands on an empty README branch instead of the code. I had to add a context7.json on master that redirects to the -3.x branch, just so the documentation index finds the harness docs. Proposed, using the same procedure as the other nine: - rename master -> maven-plugin-testing-4.x. It keeps the README pointing to Maven core, and could also become an archive tag instead. - rename maven-plugin-testing-3.x -> master, and make it the default branch. - carry .asf.yaml, .github and the README over in a pre-staging PR. The protected_branches entry needs updating too. There are no open PRs in the repository, so nothing needs retargeting, and no release is in progress. I'm happy to prepare the pre-staging PR. Regards, Sylwester On Mon, Oct 19, 2026 10:02 AM, Gerd Aschemann <[email protected]> wrote: > The branch-default switch for maven-sources#57 is done. All nine > plugins/components now have their default branch back on the Maven 3 line, > with the Maven 4 line preserved on a <repo>-4.x branch: > > core plugins: maven-clean-plugin, maven-compiler-plugin, > maven-deploy-plugin, maven-install-plugin, maven-resources-plugin > packaging: maven-jar-plugin, maven-source-plugin > shared: maven-archiver, maven-filtering > > For each repo the end state is: default = master = Maven 3 line; > <repo>-4.x = Maven 4 line. As expected from the rename-based approach, > GitHub auto-retargeted the open PRs onto the <repo>-4.x line, and the > repo-wide, default-branch-sourced configuration (.asf.yaml, .github > templates, Jenkins/badge links) was carried over by the pre-staging PRs, so > nothing was silently dropped. > > We ran it as announced: a single pilot (maven-filtering) first to validate > the whole procedure end to end, then the rest in one batch, and -- as > agreed -- maven-archiver and maven-jar-plugin only once their releases > (Maven Archiver 4.0.0-beta-6 and Maven JAR Plugin 4.0.0-beta-2) were out. > > Still open, as a separate step: the special case maven-plugin-tools (no > swap; its master stays on the Maven 3 line, the -3.x branch is dropped and > the version renamed). I'll handle that on its own and report back here. > > Thanks to: > - INFRA for performing the protected-branch renames, > - the reviewers of the nine pre-staging PRs, and > - Guillaume for getting the archiver and jar releases out, which let > those two join the same batch. > > Follow-up for fork owners: the upstream rename does not touch your fork. > Your fork's master still holds the old (Maven 4) content; realigning it > (e.g. rename your master -> <repo>-4.x and track the new upstream master = > Maven 3) is a one-time manual step, described in the runbook: > > https://cwiki.apache.org/confluence/x/85fwGg > > Regards, > Gerd > > > On 19. Oct 2026, at 08:35, Gerd Aschemann <[email protected]> wrote: > > > > Meanwhile, the pilot repo (maven-filtering) switch was completed by > Infra (thanks!). If you open the repo in GH it now greets you with a > message that the default branch was renamed: > > > > <PastedGraphic-1.png> > > > > The open PR was auto-retargeted onto the Maven 4 line, the Maven 3 > branch became the new master, and no configuration was dropped. > > > > So we're continuing with the next six, all reviewed and approved, using > the exact same procedure: > > > > - maven-clean-plugin > https://github.com/apache/maven-clean-plugin/pull/366 > > - maven-compiler-plugin > https://github.com/apache/maven-compiler-plugin/pull/1169 > > - maven-deploy-plugin > https://github.com/apache/maven-deploy-plugin/pull/718 > > - maven-install-plugin > https://github.com/apache/maven-install-plugin/pull/467 > > - maven-source-plugin > https://github.com/apache/maven-source-plugin/pull/340 > > - maven-resources-plugin > https://github.com/apache/maven-resources-plugin/pull/539 > > > > Two components stay out of this batch for now: maven-archiver and > maven-jar-plugin, because their release votes are not officially closed > yet. Those will follow in a separate, later swap once they are ready. > > > > I'll report again once this batch is done. > >> On 18. Oct 2026, at 22:33, Gerd Aschemann <[email protected]> wrote: > >> > >> 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] <mailto: > [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 -- [email protected] <mailto:[email protected]> -- > https://aschemann.net <https://aschemann.net/> > >>>> > >>> > >>> -- > >>> Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) > >>> +49/173/3264070 -- [email protected] <mailto:[email protected]> -- > http://www.aschemann.net <http://www.aschemann.net/> > >>> > >> > >> -- > >> Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) > >> +49/173/3264070 -- [email protected] <mailto:[email protected]> -- > http://www.aschemann.net <http://www.aschemann.net/> > > -- > > Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) > > +49/173/3264070 -- [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 > >
