-
-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC]: Support optional <major>.x as branch name for upcoming releases #84
Comments
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:
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. |
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 |
Yes, re-targeting is required anyway, as minor release branches become maintenance branches once a major is released. I see what you mean though:
Seems sensible, but also seems more reasonable for the tool to automate some re-targeting work instead? Specifically, when releasing (tag) Would that be a better solution? It would automate moving on things for everyone that has an old PR open against an old minor 🤔 |
RFC
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:<major>.<minor>.x
branch already exists, the tool works the same way it does now.<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.<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:<major>.x
branch always takes precedence over<major>.<minor>.x
<major>.x
branch never takes precedence over<major+1>.<minor>.x
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.
The text was updated successfully, but these errors were encountered: