For the exact details of the version mismatch detection + mechanism, please refer to the relevant entry in the FAQ. +
No breaking changes to report.
Given its huge installed user base, the version check - performed by SLF4J API during its initialization is an - elective process. Conforming SLF4J implementations may choose - not to participate, in which case, no version check - will be performed. +
The version check performed by SLF4J API during its + initialization is an elective process. Conforming SLF4J + implementations may choose not to participate, in + which case, no version check will be performed.
-However, if you decide to participate, your SLF4J binding
- needs to declare a variable called REQUESTED_API_VERSION
- within your copy of the StaticLoggerBinder
- class. The value of this variable should be equal to the
- version of the slf4j-api.jar you are compiling against. If you
- ugrade to a newer version of slf4j-api, you also need to
- update the value of REQUESTED_API_VERSION. (That is all you
- have to do.)
+
However, if an SLF4J implementation decides to participate,
+ than it needs to declare a variable called
+ REQUESTED_API_VERSION within its copy of the
+ StaticLoggerBinder class. The value of this
+ variable should be equal to the version of the slf4j-api.jar
+ it is compiled with. If the implementation is upgraded to a
+ newer version of slf4j-api, than you also need to update the
+ value of REQUESTED_API_VERSION.
For earch version, SLF4J API maintains a list of compatible +
For each version, SLF4J API maintains a list of compatible versions. SLF4J will emit a version mismatch warning only if the requested version is not found in the compatibility list. So even if your SLF4J binding has a different release - schedule than SLF4J, you can still participate in the version - check without incurring a mismatch warning. For example, - logback has a different release schedule but still + schedule than SLF4J, assuming you update the SLF4J version you + use every 6 to 12 months, you can still participate in the + version check without incurring a mismatch warning. For + example, logback has a different release schedule but still participates in version checks.
-As of SLF4J 1.5.5, all bindings shipped within SLF4J - distribution, e.g. slf4j-logj12, slf4j-simple and slf4j-jdk14, - declare the REQUESTED_API_VERSION field with a value equal to - their SLF4J version. It follows that, for example if - slf4j-simple-1.5.6.jar is mixed with simple-api-1.5.5.jar, - then a version mismatch warning will be issued. Note that - SLF4J prior to 1.5.5 did not have a version check - mechanism. (Actually, version 1.5.4 offered a check policy - which was much too restritive and inconsistent with the size - of our user base. Consequently, SLF4J version 1.5.5 was - released just a day after 1.5.4.) +
As of SLF4J 1.5.5, all bindings shipped within the + SLF4J distribution, e.g. slf4j-logj12, slf4j-simple and + slf4j-jdk14, declare the REQUESTED_API_VERSION field with a + value equal to their SLF4J version. It follows that, for + example if slf4j-simple-1.5.6.jar is mixed with + slf4j-api-1.5.5.jar, then a version mismatch warning will be + issued. Note that SLF4J versions prior to 1.5.5 did not have a + version check mechanism. Only slf4j-api-1.5.5.jar and later + can emit version mismatch warnings. (Actually, version 1.5.4 + offered a check policy which was much too restrictive and + inconsistent with the size of our user base. Consequently, + SLF4J version 1.5.5 was released just a day after 1.5.4.)
-+
Given its huge installed user base and several external + implementations, it would have been unwise to expect all SLF4J + implementations to closely follow SLF4J's release schedule, + let alone align their release schedules with SLF4J. Hence, the + elective version check policy.
The version check mechanims introduced in SLF4J 1.5.4 was + inconstent with the large size of SLF4J's installed user base. We + cannot expect external SLF4J to align their release schedule with + that of SLF4J. Consequently, this SLF4J version, namely 1.5.5, + retains versions checks but as an elective process. For further + details see the relevant entry + in the FAQ. +
+ +You are highly encouraged to upgrade to SLF4J version 1.5.5. The + upgrade should pose no problems. Nevertheless, you might still want + to refer to the SLF4J compatibility + report. +
+This version corrects critical bugs. You are highly encouraged to - upgrade to SLF4J version 1.5.4. The upgrade should pose no - problems. Nevertheless, you might still want to refer to the compatibility report for this - version. +
This version corrects critical bugs.
Fixed