Hi Sylwester,
Thanks -- and you're right, maven-plugin-testing is genuinely the odd one
out. I checked: master is just the stub (.asf.yaml, .github, LICENSE/NOTICE,
README, plus your context7.json redirect), the real Maven 3 harness (3.5.1
released, 3.5.2-SNAPSHOT) is on maven-plugin-testing-3.x, there are no open
PRs, and no release is in flight. +1 from me to doing it.
The nice part: with no open PRs, this is simpler than the nine. The whole
reason we needed the branch *rename* (and thus INFRA) for the nine was to
auto-retarget the ~45 open PRs onto the -4.x line. Here there is nothing to
retarget, so you can do it entirely self-service as a PMC member, with no
INFRA step:
- create maven-plugin-testing-4.x (or just a tag) from the current master,
to preserve the stub/README;
- flip the default branch to the Maven 3 line via the Gitbox "boxer"
action (PMC-only, which you are):
https://gitbox.apache.org/boxer/?action=defaultbranch
One thing to decide, because boxer repoints the default to an *existing*
branch (it doesn't rename): the straightforward version leaves the default
named maven-plugin-testing-3.x. A casual clone then lands on the Maven 3
harness -- which is the real goal -- but it would be the only Maven repo
whose default branch isn't called master. If you also want it named master
(for consistency with the rest), that part still needs either a rename (the
one INFRA step, as for the nine) or a little branch juggling afterwards
(boxer to -3.x, recreate master from it, boxer to master). Force-pushing
master isn't an option -- branch protection blocks it. Your call as the one
driving it; I'd personally take the small branch-juggle or a single INFRA
rename to keep the master name, but the plain boxer switch is the least
effort if the -3.x default name is acceptable.
On the pre-staging side, same as the nine: a PR that carries .asf.yaml
(incl. the protected_branches entry), .github and the README onto the branch
that becomes the default, merged before the switch -- runbook details:
https://cwiki.apache.org/confluence/x/85fwGg . Once the Maven 3 line is the
default, the context7.json redirect you added can be dropped or repointed,
since the harness docs then live on the default branch directly.
No need to route any of this through me -- happy to answer anything or
review the pre-staging PR. I'll note maven-plugin-testing as a follow-up on
maven-sources#57 so it's recorded alongside the nine.
Regards,
Gerd
> On 8. Nov 2026, at 11:20, Sylwester Lachiewicz <[email protected]> wrote:
>
> 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
>>
>>
--
Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas)
+49/173/3264070 -- [email protected] -- http://www.aschemann.net
