Better default branch rules

[weierophinney]

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	yes, but in a good way

Summary

When a branch targetting a new major exists, no releases have been made for that new major, and a release against current major is created, the action will set the default branch to the new major branch on completion.
This causes maintenance issues, as:

• New bugfixes and features coming in are created against the new major branch.
• Renovate creates patches against the new major branch.

As the new major is often a long-lived branch while longer refactoring is performed, these mean that the maintainer and/or contributor have to retarget pull requests, and, worse, a new minor branch for the existing major needs to be manually created and pushed before doing so.

The expected behavior:

• When a release is created,
  • The next release branch should always be calculated as a new minor.
• If the calculated new branch version is higher than the default branch version
  • Then set the new branch version as the default branch.
  • Else, do not reset the default branch.

(Discussed during the September 2022 TSC meeting.)

[Ocramius]

This is currently handled by querying the latest release branch:

automatic-releases/src/Git/Value/MergeTargetCandidateBranches.php

Lines 73 to 76 in 61eb712

	public function newestReleaseBranch(): BranchName|null
	{
	return Iter\first(Vec\reverse($this->sortedBranches));
	}

We would probably use a different API for that (need a better name for it). Something like nextMinorBranchName or such?

Also to be noted: how do we deal with a merge-up like follows?

• 3.0.x exists
• 2.1.0 tagged from 2.1.x
• 2.2.x created
• create merge-up from 2.1.x to 3.0.x anyway?

This scenario can be unit-tested, doesn't need an integration test.

[internalsystemerror]

Looking into whether checking only the minor version would work, I noticed this, which looks like it may be incompatible:

automatic-releases/feature/default-branch-switching.feature

Lines 43 to 63 in 61eb712

	Scenario: A pre-existing branch of a greater major release is set as default branch on release
	Given following existing branches:
	| branch |
	| 1.0.x |
	| 1.1.x |
	| 1.2.x |
	| 2.0.x |
	| 2.1.x |
	And following open milestones:
	| name |
	| 1.2.0 |
	And the default branch is "1.0.x"
	When I close milestone "1.2.0"
	Then these should be the existing branches:
	| branch |
	| 1.0.x |
	| 1.1.x |
	| 1.2.x |
	| 2.0.x |
	| 2.1.x |
	And the default branch should be "2.1.x"

I was thinking to involve checking tags, but it doesn't look like they're currently pulled. We could handle the minor version 0/next major as a special case?

[internalsystemerror]

I gave it a go anyway, Also, I've updated the default-branch-switching.feature file to document my intentions by the PR.