I don't think there is a safe way to resolve this because it would mean that logback would need to broadcast support for future versions of slf4j, which it simply cannot do.
I can see a couple of options going forward:
1. When SLF4J releases a major (X.0) or minor (1.X) version, update Logback and release it ASAP. Projects want to use SLF4J as the Logging API and Logback as the driver. If Logback is too slow to update, this gives projects the incentive to use Log4J as the SLF4J driver instead as the logging driver because this pairing allows the project to stay current on SLF4J.
2. Change Logback so that it depends on SLF4J API rather than including them. This would mean Logback will need a new driver-style API and a "SLF4J-over-Logback" adapter to connect the two.
I can see a couple of options going forward:
1. When SLF4J releases a major (X.0) or minor (1.X) version, update Logback and release it ASAP. Projects want to use SLF4J as the Logging API and Logback as the driver. If Logback is too slow to update, this gives projects the incentive to use Log4J as the SLF4J driver instead as the logging driver because this pairing allows the project to stay current on SLF4J.
2. Change Logback so that it depends on SLF4J API rather than including them. This would mean Logback will need a new driver-style API and a "SLF4J-over-Logback" adapter to connect the two.