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
I'm currently scrolling through the open issues, trying to close all that are done, and I stumbled upon #4644, fixed by #4875, which I had hoped would be backported/released/not-kept-in-limbo. I also shied away from labelling it myself, hence it fell through the cracks, and missed the v0.27.8 release brouhaha, hence it shipped without that fix, which would have made me more comfortable about those weird OpenSSL failures.
Hence, I'd like to discuss how should to best manage the labels for releases. Right now, @pks-t started the trend of the backport-$version labels, which I find useful, but I don't think they would scale, and there's a next-release label, which @ethomson used for the recent changelog, but is much more ancient.
Proposal
I don't think we need the full version in the backport labels, so I'm tempted to switch to MAJOR.MINOR. This limits us, in that we loose (unless you have crazy git skills) the ability to tell at a glance whether a given release has the given fix, but keeps the amount of labels down (we're still v0, and there's already 5 of them), which is what I'm afraid won't scale (I envision a world with a v1.0, v1.1 and v1.2 maintenance branches + master/v1.3, that might be a lot of labels).
Any merged PR on master gets the next-release label (unless it's targeting a maintenance branch, in which case it gets a backport), and we can discuss if it's eligible for a backport (and where) at that time, and the PR gets tagged as such.
When preparing a release, you have all the labels needed to know what's going in. For a maintenance release, look at backport, for a new branchpoint, look at next-release. The release is done, unlabel all those we used, and we can start over.
Does that feel like a plan ?
Some additional notes :
I'm unable to do some of the crazier things you can do with git, like identifying whether a given commit has appeared in another branch as a backport, so if you can enlighten be I'd be glad.
I'm unsure what was the original motivation behind the full backport labels, so maybe this is contradicting some meaning I'm unaware of (hence, this discussion).
This discussion was converted from issue #5867 on May 12, 2021 14:10.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I'm currently scrolling through the open issues, trying to close all that are done, and I stumbled upon #4644, fixed by #4875, which I had hoped would be backported/released/not-kept-in-limbo. I also shied away from labelling it myself, hence it fell through the cracks, and missed the v0.27.8 release brouhaha, hence it shipped without that fix, which would have made me more comfortable about those weird OpenSSL failures.
Hence, I'd like to discuss how should to best manage the labels for releases. Right now, @pks-t started the trend of the
backport-$version
labels, which I find useful, but I don't think they would scale, and there's anext-release
label, which @ethomson used for the recent changelog, but is much more ancient.Proposal
I don't think we need the full version in the
backport
labels, so I'm tempted to switch toMAJOR.MINOR
. This limits us, in that we loose (unless you have crazy git skills) the ability to tell at a glance whether a given release has the given fix, but keeps the amount of labels down (we're still v0, and there's already 5 of them), which is what I'm afraid won't scale (I envision a world with a v1.0, v1.1 and v1.2 maintenance branches + master/v1.3, that might be a lot of labels).Any merged PR on
master
gets thenext-release
label (unless it's targeting a maintenance branch, in which case it gets abackport
), and we can discuss if it's eligible for abackport
(and where) at that time, and the PR gets tagged as such.When preparing a release, you have all the labels needed to know what's going in. For a maintenance release, look at
backport
, for a new branchpoint, look atnext-release
. The release is done, unlabel all those we used, and we can start over.Does that feel like a plan ?
Some additional notes :
I'm unable to do some of the crazier things you can do with git, like identifying whether a given commit has appeared in another branch as a backport, so if you can enlighten be I'd be glad.
I'm unsure what was the original motivation behind the full backport labels, so maybe this is contradicting some meaning I'm unaware of (hence, this discussion).
Beta Was this translation helpful? Give feedback.
All reactions