Let Dependabot update master, not only the 3.x branch

[slachiewicz]

Both entries in dependabot.yml carry target-branch: "maven-plugin-testing-3.x". That setting replaces the default target rather than adding to it, so Dependabot has only ever proposed updates for the maintenance branch — nothing has been proposed for master since it was added.

The effect is visible in the workflows, and it is the wrong way round:

maven-plugin-testing-3.x   pr-automation.yml    @v5
                           release-drafter.yml  @v5
                           maven-verify.yml     @v5

master                     pr-automation.yml    @v4
                           release-drafter.yml  @v4

The maintenance branch is ahead of the default branch, because its bump PRs (#276, #277, #278) landed there and master never got any.

This adds the same two ecosystems again without target-branch, so master is covered. The existing 3.x entries are untouched — purely additive, four entries instead of two.

Found while working through apache/maven-gh-actions-shared#247, which tracks moving the org off the v4 shared workflows. This repository is the only one in the org with this inversion; the other 84 with a github-actions ecosystem all cover their default branch.

Once this merges Dependabot should propose the @v4 → @v5 bumps for master on its next run.

[slachiewicz]

Closing this — I had the diagnosis backwards.

I read target-branch: maven-plugin-testing-3.x on both entries as a misconfiguration that left master uncovered. It is not: this component has been merged into the Maven core repository, and master here is a tombstone. The README says so directly:

Maven Plugin Testing has been merged into Maven core repository.
Branches are still available:

• maven-plugin-testing-3.x for Maven 3.x

So pointing Dependabot at maven-plugin-testing-3.x only is exactly right — it is the one branch still alive. Adding default-branch entries would have generated update PRs against a branch nobody develops on.

That also explains what I took as evidence of the bug: the 3.x branch being on @v5 while master sits on @v4 is not the maintenance line running ahead of the default branch, it is the live branch being maintained and the dead one being left alone. master staying on @v4 is not a problem to fix.

Apologies for the noise.