openharmony/third_party_rust_log
1
0
Fork 0
mirror of https://gitee.com/openharmony/third_party_rust_log synced 2024-11-27 01:40:27 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fix formatting

Browse Source
This commit is contained in:
Steven Fackler 2017-12-24 15:11:01 -07:00
parent 037b87d0a6
commit 0a3c0adb29
1 changed files with 13 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
CHANGELOG.md
View File

@ -4,29 +4,25 @@
## [0.4.0] - 2017-12-24
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.
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.
### Compatibility
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.
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
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.
**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.
### New