-
Notifications
You must be signed in to change notification settings - Fork 2
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
dlog: Fix issue where the fast-logging broke backward compat #33
Conversation
Signed-off-by: Luke Shumaker <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I consider the non-optimized logger a design flaw, I'd prefer if this PR wasn't merged and the version instead bumped to 2.0.0. That way the backward compatibility wouldn't be broken for 1.x users and the flaw could still be removed.
@@ -47,13 +50,38 @@ type Logger interface { | |||
StdLogger(LogLevel) *log.Logger | |||
|
|||
// Log actually logs a message. | |||
Log(level LogLevel, args ...interface{}) | |||
Log(level LogLevel, msg string) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverting this will break Telepresence, which I assume is OK, given that we're not using a released version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh dang, you guys finally upgraded?
Yeah, it's a bad situation because 1.2.4 has been around so long. Do you break the folks who have upgraded to 1.2.4, or break the folks who are on older versions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this lgtm from a code perspective, i do kind of agree we might wanna release a 2.0.0 but im okay with unbreaking the 1.x line for now
I don't think I agree. I think keeping the required-interface minimal and letting dlog handle as much complexity as it can is a good thing. |
I've created a "v2" milestone and an issue within it to revisit the |
A 2.0 version would be good for three reasons.
My motivation for calling the old version flawed is that unnecessary string manipulation is expensive and the added complexity is very trivial. In fact, in most cases it's just delegated to another log implementation. |
#28 changed the
Logger
interface, breaking any existing implementors of the interface. That's not OK.So revert that interface (and add a comment about how it's frozen), and add an opt-in
OptimizedLogger
interface for Jose's optimizations.