[slf4j-dev] [JIRA] Updates for SLF4J-495: Binary compatibility between release and alpha version

[QOS.CH (JIRA)]

SLF4J / SLF4J-495 [Open]
Binary compatibility between release and alpha version

==============================

Here's what changed in this issue in the last few minutes.
This issue has been created
This issue is now assigned to you.

View or comment on issue using this link
https://jira.qos.ch/browse/SLF4J-495

==============================
 Issue created
------------------------------

Alexander Krimm created this issue on 15/Jul/20 3:24 PM
Summary:              Binary compatibility between release and alpha version
Issue Type:           Bug
Affects Versions:     2.0.0-alpha0, 2.0.0-alpha1
Assignee:             SLF4J developers list
Components:           Core API
Created:              15/Jul/20 3:24 PM
Environment:
  Linux 64bit, openjdk 11.0.4
  
  SLF4J: 2.0.0-alpha0 (compile-time), 1.7.30 (run-time)
  Logging Provider: log4j-slf4j-impl 1.13.3
Labels:               configuration documentation
Priority:             Major
Reporter:             Alexander Krimm
Description:
  As I understand [http://slf4j.org/manual.html#compatibility] it should be possible to compile a library against slf4j-api 2.0.0-alpha0 and at runtime have slf4j-api-1.7.30.jar and a corresponding implementation e.g. log4j-slf4j-impl-1.13.3.jar on the classpath.
  
  However, when using the fluent api, this setup throws whenever a (fluent) Logging statement is hit:
  
  {code}
  java.lang.NoSuchMethodError: 'org.slf4j.spi.LoggingEventBuilder org.slf4j.Logger.atInfo()'
  {code}
  
   
  
  Is binary compatibility restricted to the same major version number, are alpha versions excluded?
  
  Effectively this seems to force all projects which have dependencies using the Fluent Logging API to also use the alpha logging API.
  
   
  
  I really like the the new API, so I hope there's some way to set this up correctly.


==============================
 This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)