You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What I have in mind is having a config structure that would allow the repo to say that the current version is X and the policy for bugfixes is X-1, the policy for security fixes is X-2 (for example).
Then, it'd allow us to implement the flow where having a bug label would trigger backports to the previous version and having security would trigger backports to two previous versions. Alternatively, this could be made explicit with needs_bug_backport / needs_security_backport (via opt-in or opt-out).
The last bit needed is to allow the repo to specify what part of the version spec to consider a bump (whether for v2.1.1 X-1 is considered v1.0.0, or v2.0.0, or v2.1.0).
What I have in mind is having a config structure that would allow the repo to say that the current version is X and the policy for bugfixes is X-1, the policy for security fixes is X-2 (for example).
Then, it'd allow us to implement the flow where having a
bug
label would trigger backports to the previous version and havingsecurity
would trigger backports to two previous versions. Alternatively, this could be made explicit withneeds_bug_backport
/needs_security_backport
(via opt-in or opt-out).The last bit needed is to allow the repo to specify what part of the version spec to consider a bump (whether for v2.1.1 X-1 is considered v1.0.0, or v2.0.0, or v2.1.0).
Depends on: #5
Depends on: #6
The text was updated successfully, but these errors were encountered: