I’m excited to announce a new major version of the log crate. The changes in this release include cleanup of some obscure functionality and a more robust public API designed to support bridges to other logging systems, and provide more flexibility to new features in the future.
Vast portions of the Rust ecosystem use the 0.3.x release series of log, and we don’t want to force the community to go through the pain of upgrading every crate to 0.4.x at the exact same time. Along with 0.4.0, we’ve published a new 0.3.9 release which acts as a “shim” over 0.4.0. This will allow crates using either version to coexist without losing messages from one side or the other.
There is one caveat - a log message generated by a crate using 0.4.x but consumed by a logging implementation using 0.3.x will not have a file name or module path. Applications affected by this can upgrade their logging implementations to one using 0.4.x to avoid losing this information. The other direction does not lose any information, fortunately!
TL;DR Libraries should feel comfortable upgrading to 0.4.0 without treating that as a breaking change. Applications may need to update their logging implementation (e.g. env-logger) to a newer version using log 0.4.x to avoid losing module and file information.
- The crate is now
serdefeature is enabled.
Metadatatypes can now be constructed by third-party code via a builder API.
loggerfree function returns a reference to the logger implementation. This, along with the ability to construct
Records, makes it possible to bridge from another logging framework to this one without digging into the private internals of the crate. The standard
warn!, etc, macros now exclusively use the public API of the crate rather than “secret” internal APIs.
Log::flushhas been added to allow crates to tell the logging implementation to ensure that all “in flight” log events have been persisted. This can be used, for example, just before an application exits to ensure that asynchronous log sinks finish their work.
shutdown_rawfunctions have been removed. Supporting shutdown significantly complicated the implementation and imposed a performance cost on each logging operation.
log_panicsfunction and its associated
nightlyCargo feature have been removed. Use the log-panics instead.
Logprefix has been removed from type names. For example,
MaxLogLevelFilterobject has been removed in favor of a
set_loggerfree functions have been restructured. The logger is now directly passed to the functions rather than a closure which returns the logger.
set_loggernow takes a
&'static Logand is usable in
no_stdcontexts in place of the old
set_boxed_loggeris a convenience function which takes a
Box<Log>but otherwise acts like
set_logger. It requires the
Recordno longer have the
'staticlifetime to support integration with other logging frameworks that don’t provide a
'staticlifetime for the equivalent values.
Options to support integration with other logging frameworks that don’t provide those values.
In the Future
- We’re looking to add support for structured logging - the inclusion of extra key-value pairs of information in a log event in addition to the normal string message. This should be able to be added in a backwards compatible manner to the 0.4.x series when the design is worked out.