kubernetes-operators icon indicating copy to clipboard operation
kubernetes-operators copied to clipboard

Published 20 hours ago • verified publisher icon sapcc

Update module github.com/go-logr/logr to v1.4.1

Open renovate[bot] opened this issue 2 years ago • 0 comments

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
github.com/go-logr/logr v1.2.0 -> v1.4.1 age adoption passing confidence

[!WARNING] Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Release Notes

go-logr/logr (github.com/go-logr/logr)

v1.4.1

Compare Source

What's Changed

Full Changelog: https://github.com/go-logr/logr/compare/v1.4.0...v1.4.1

v1.4.0

Compare Source

This release dramatically improves interoperability with Go's log/slog package. In particular, logr.NewContext and logr.NewContextWithSlogLogger use the same context key, which allows logr.FromContext and logr.FromContextAsSlogLogger to return logr.Logger or *slog.Logger respectively, including transparently converting each to the other as needed.

Functions logr/slogr.NewLogr and logr/slogr.ToSlogHandler have been superceded by logr.FromSlogHandler and logr.ToSlogHandler respectively, and type logr/slogr.SlogSink has been superceded by logr.SlogSink. All of the old names in logr/slogr remain, for compatibility.

Package logr/funcr now supports logr.SlogSink, meaning that it's output passes all but one of the Slog conformance tests (that exception being that funcr handles the timestamp itself).

Users who have a logr.Logger and need a *slog.Logger can call slog.New(logr.ToSlogHandler(...)) and all output will go through the same stack.

Users who have a *slog.Logger or slog.Handler can call logr.FromSlogHandler(...) and all output will go through the same stack.

What's Changed
New Contributors

Full Changelog: https://github.com/go-logr/logr/compare/v1.3.0...v1.4.0

v1.3.0

Compare Source

This release adds support for slog in a new, self-contained logr/slogr package. Implementers of a logr.LogSink are encouraged, but not required, to extend their implementation to improve the quality of log output coming from a slog API call.

Breaking change: the call depth for LogSink.Enabled when called via Logger.Enabled was fixed to be the same as for other call paths. Implementers of a LogSink who have worked around this bug will need to remove their workarounds.

Security best practices were improved. Only Go versions >= 1.18 are supported by this release.

What's Changed

New Contributors

Full Changelog: https://github.com/go-logr/logr/compare/v1.2.4...v1.3.0

v1.2.4

Compare Source

This is a collection of small bugfixes and documentation updates.

NOTE: A change (https://github.com/go-logr/logr/pull/166) which was thought to be compatible seems to be a breaking change. In particular, one used to be able to differentiate the result of Discard() from Logger{}. After this change, those are the same. We are considering how to address this, but do not currently plan to revert this change. Apologies!

What's Changed

New Contributors

Full Changelog: https://github.com/go-logr/logr/compare/v1.2.3...v1.2.4

v1.2.3

Compare Source

This is a minor release.

What's Changed

New Contributors

Full Changelog: https://github.com/go-logr/logr/compare/v1.2.2...v1.2.3

v1.2.2

Compare Source

Bugfix release

  • funcr: Add a new Option MaxLogDepth which controls how many levels of nested fields (e.g. a struct that contains a struct that contains a struct, etc.) it may log. Every time it finds a struct, slice, array, or map the depth is increased by one. When the maximum is reached, the value will be converted to a string indicating that the max depth has been exceeded. If this field is not specified, a default value will be used.

v1.2.1

Compare Source

This is a minor bugfix release.

  • logr: Clarify the Error() semantics. 1) Error messages are always printed (they do not follow V()) and the error argument may be nil.
  • funcr: When using RenderValuesHook func would save the "cooked" result, so repeated calls to WithValues() would not merge properly.

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • [ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

renovate[bot] avatar Jul 21 '22 14:07 renovate[bot]