[RFC]: Support optional <major>.x as branch name for upcoming releases

[alcaeus]

RFC

Q	A
Proposed Version(s)	x.y.0
BC Break?	Not sure

Goal

Consider branch names of the form <major>.x as source for releases when tagging <major>.<minor>.0 releases.

Background

Currently, the tool requires a branch name in the form <major>.<minor>.x to be present to create a new release. If this branch does not exist, the tool halts with an error. Furthermore, the tool makes this branch the new default branch in the repository unless a newer release branch (<major+1>.*.x or <major>.<minor+1>.x) exists.

This last part can be an issue, as it requires re-targeting pull requests to the new default branch, which can be cumbersome. Thus, I propose adding support for development branches that follow the <major>.x syntax. This branch can be considered a development branch for the upcoming minor version of the indicated major release series.

The behaviour of the tool when closing a <major>.<minor>.0 milestone would change as follows:

• If a <major>.<minor>.x branch already exists, the tool works the same way it does now.
• If the above branch does not exist, but a <major>.x branch exists, the tool creates and pushes a <major>.<minor>.x branch created from <major>.x, then proceeds as if the branch existed beforehand.
• If neither <major>.<minor>.x branch nor <major>.x branch exists, the tool halts with an error as it does now.

When updating default branches, the tool should consider <major>.x branches as well. Instead of choosing the latest <major>.<minor>.x branch, the following rules apply:

• a <major>.x branch always takes precedence over <major>.<minor>.x
• a <major>.x branch never takes precedence over <major+1>.<minor>.x
• no change is necessary in situation where the release tool currently decides not to update the default branch.

Considerations

I don't expect any negative impact on users due to this change, but a toggle to enable this behaviour can be considered to require users to opt-in to this new behaviour.

Proposal(s)

I can create a PR for the change, but wanted to check with the maintainers before investing the time to do so.

Appendix

If the proposal above is accepted, another approach would be to define a general fallback name as release source for when the release branch does not exist. However, that is not part of this proposal as there are more cases to consider.

[Ocramius]

which can be cumbersome.

I'd say that instead of making an exclusion for a one-off scenario that will solve itself with the next major release, doing a bulk update of pre-existing PRs (via API) is more acceptable.

Effectively:

1. query for all open PRs
2. filter for (if not feasible during query) issues targeting <major>.x
3. apply base branch update

This is a one-off data change that avoids requiring a long term code addition to be tested and checked for regressions in the codebase here.

[alcaeus]

I'd say that instead of making an exclusion for a one-off scenario that will solve itself with the next major release, doing a bulk update of pre-existing PRs (via API) is more acceptable.

Not sure I understand: with the current workflow, wouldn't every new minor release require re-targeting pull requests that introduce features to the upcoming release branch? My suggestion would limit this to only being required for new major releases.

The way I understand, the only workaround at this time is to manually manage the default branch and manually create release branches before tagging <major>.<minor>.x.

[Ocramius]

Yes, re-targeting is required anyway, as minor release branches become maintenance branches once a major is released.

I see what you mean though:

• major release work goes to <major>.x
• major release fixup work goes to <major>.0.x

Seems sensible, but also seems more reasonable for the tool to automate some re-targeting work instead?

Specifically, when releasing (tag) <major>.<minor>.0, all open PRs targeting (branch) <major>.<minor>.x get re-targeted to <major>.<minor+1>.x.

Would that be a better solution? It would automate moving on things for everyone that has an old PR open against an old minor :thinking: