[HOLD until maven-sources#57 swap] Switch default-branch metadata to Maven 3 (.asf.yaml + README)

[ascheman]

Part of apache/maven-sources#57 (switching plugin default branches back to Maven 3, cf. Plan / runbook).

⛔ DO NOT MERGE before the swap. This PR should be merged immediately around the branch rename on 2026-10-18 (coordinated with INFRA). Please review/approve by 2026-10-16 so it can be merged right at the switch.

What changes

.asf.yaml

This makes this branch's .asf.yaml identical to the current master's, with the only intended difference being the protected-branch name swap (maven-filtering-3.x → maven-filtering-4.x).

Why that's needed: ASF asfyaml only honours the default branch's .asf.yaml. Several settings therefore live only on today's master and are absent on this (-3.x) branch, which is dormant until the swap. When maven-filtering-3.x becomes the new default master, it must carry them or they'd be silently dropped. Here that means adding protected_branches (master + maven-filtering-4.x), pull_requests.del_branch_on_merge and features.issues.

No default_branch is added — the current master has none, and the default pointer is set back to master by INFRA as part of the renames, not via .asf.yaml.

⚠️ Alignment with the current master (please flag if any of this is unwanted)

To keep the new master's .asf.yaml byte-identical to today's master (so the swap introduces no silent config drift), this PR also removes one branch-only line that exists on maven-filtering-3.x but not on master:

• notifications.jira_options: link label comment

Rationale: it is not on master, and with the Maven JIRA → GitHub-issues migration it is effectively vestigial. If you want it kept on the Maven 3 line, say so in review and we'll restore it.
(In sibling repos the same alignment also drops a -3.x-only autolink_jira where master has none — not applicable here; flagged for consistency.)

README.md

Repoints the Jenkins / badge / tree links to the post-swap scheme: the Maven 3 line → job/master, the Maven 4 line → job/maven-filtering-4.x (+ tree/maven-filtering-4.x). The reproducible-central /master/ paths (a different repo) are left untouched; the Maven Central filter=3* stays on the Maven 3 block.

.github/

.github/ is read from the default branch, so the swap must carry it or it would silently drop. This PR:

• adds the repo-wide, default-sourced files that maven-filtering-3.x was missing vs master: the .github/ISSUE_TEMPLATE/ forms and the scheduled .github/workflows/stale.yml (otherwise issue templates and the stale bot would stop working after the swap);
• aligns one repo-wide file to master's current version: pull_request_template.md (the -3.x one was an older variant);
• keeps the Maven 3 line's line-specific pieces unchanged: .github/dependabot.yml, the release-drafter config, the release-drafter workflow, and the maven-verify CI workflow. (The release-drafter workflow is disabled_manually on the repo, so its on.push.branches filter never runs — aligning it would be runtime-moot, so it stays the Maven 3 line's own. Thanks @slawekjaranowski.)

(Flagged for review — thanks @slawekjaranowski for raising this: if any of the repo-wide takeovers isn't wanted, say so.)

Short inconsistency window after merge

These URLs only become correct once the rename completes and Jenkins re-discovers the branches:

• job/master is today still the Maven 4 job (becomes Maven 3 after the rename);
• job/maven-filtering-4.x and tree/maven-filtering-4.x don't exist yet (created by the master → maven-filtering-4.x rename);
• Jenkins multibranch discovery may lag briefly after the rename.

So between merge and the completed rename (+ CI sync) there is a short window of dead badges / links pointing at not-yet-existing branches. This is expected and resolves once the 2026-10-18 swap finishes.

[slawekjaranowski]

You also take care about .github directory content, eg

• issue, PR templates
• dependabot configuration
• cron workflows - stale

are taken from default branch

[ascheman]

You also take care about .github directory content, eg

• issue, PR templates
• dependabot configuration
• cron workflows - stale

are taken from default branch

Good catch, thanks @slawekjaranowski — you're right. On maven-filtering the maven-filtering-3.x branch was missing .github/ISSUE_TEMPLATE/ and the scheduled .github/workflows/stale.yml that master has, so after the swap the issue templates and the stale bot would have silently stopped. I've added those repo-wide, default-sourced .github/ bits to this PR. The line-specific config (maven-verify CI, dependabot targets) stays the Maven 3 line's, which is what the new master should run. I'll note .github/ explicitly in the plan (and run the same check on the other repos).

[slawekjaranowski]

Did you test how release drafter will generate drafts after change ...

By the way action is disabled ... https://github.com/apache/maven-filtering/actions/workflows/release-drafter.yml
It is intentional?

[ascheman]

By the way action is disabled ... https://github.com/apache/maven-filtering/actions/workflows/release-drafter.yml It is intentional?

@slawekjaranowski Not disabled by this PR — Release Drafter is already disabled_manually on the repo itself (independent of any branch or the default), so the workflow won't run from any branch regardless of its on.push.branches filter.

That makes the branch-filter alignment I'd put in here runtime-moot, so I've reverted it: this PR now leaves .github/workflows/release-drafter.yml exactly as the Maven 3 line (maven-filtering-3.x) already has it. Same principle as the rest of the .github/ carry-over — we only pull over content that actually takes effect from the default branch (issue/PR templates, the stale cron); a disabled workflow doesn't, so it stays the line's own.

Did you test how release drafter will generate drafts after change

It generates nothing today (disabled), and the swap doesn't change that. If the Maven 3 line ever re-enables it, fixing the filter is a separate, line-local step for whoever turns it back on.