-
Notifications
You must be signed in to change notification settings - Fork 78
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
PR #166 introduced a breaking change in a patch release #180
Comments
@thockin as discussed on Slack. |
Pasting (slightly edited) short note from sloack so I don't lose it: So you can't tell if they intentionally gave you a Discard() or just "don't care". You're right that this change had an unforeseen breaking implication. Sorry about that! I updated the release notes. We probably don't want to revert that change, so let's think. Logger is a value and we've (intentionally) made the zero value useful. If you need a caller has to pass something in, I would either make the argument a Discard logger already returns false for |
I don't think we ever promised that There is a comment that pointer to a logger should be used when detecting "no logger" is important: Lines 130 to 133 in 5d57712
Ignore the comment in that section about the null logger, that is out-dated. But it doesn't change the recommendation. |
Oops! We should fix that comment!
…On Mon, Apr 24, 2023, 12:43 AM Patrick Ohly ***@***.***> wrote:
logr.Logger{} != logr.Discard()
I don't think we ever promised that logr.Discard() is or is not equal to
the zero value. The API only guaranteed that the Logger value can be
compared and that logr.Discard always returns an equal value.
There is a comment that pointer to a logger should be used when detecting
"no logger" is important:
https://github.com/go-logr/logr/blob/5d5771278ebb6b08180d7cfd806af158964ebfc1/logr.go#L130-L133
Ignore the comment in that section about the null logger, that is
out-dated. But it doesn't change the recommendation.
—
Reply to this email directly, view it on GitHub
<#180 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKWAVCWHJYDDBPO2J5YYCTXCYVILANCNFSM6AAAAAAXEIPAUI>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
|
-> #182 |
@makkes - Given that we don't want to revert this - the options are either a) you use Are we OK to close this? |
We already fixed our code and removed the conditional, basically opting for case b) you gave above. Thanks for the clarification on expectations here, everyone! |
We (the Flux team) ran into a bug related to this PR. From our perspective the PR is breaking the assumption that
logr.Logger{} != logr.Discard()
and it actually led to a bad bug experienced by some of our users.Since the change was introduced as part of a logr patch release (1.2.4) I wanted to let you know (and discuss) that this might be pretty unexpected given it's "just" a patch release and not a minor or major release and that the logr project states to be strict about following semver.
Don't get me wrong, please. I think the change introduced in #166 is very good, it's just the unfortunate inclusion of it in a patch release that might lead to unforseen bugs in dependent code.
I'm happy to hear your people's opinion on this.
The text was updated successfully, but these errors were encountered: