Plans on updating slf4j to 2.0

[danicheg]

Here I propose to discuss plans on migrating slf4j to 2.0. Since this migration isn't binary compatible we can't do this within the current major series. So we pinned its updates for now.
Ross has dropped some thoughts about it:

If I'm understanding that correctly, when we merge this, we're forcing an implementation upgrade on every application. Then I absolutely agree it's a major release for us.
Until we merge it, anybody who upgrades their implementation would have to upgrade the API. Hopefully 2.0 implementations transitively pull in the 2.0 API? And if that's the case, is there any reason libraries shouldn't just stick to 1.x?

So this is a good entry point to start the discussion.

[armanbilge]

Another way to avoid major version is to create a slf4j2 module. Then you can choose which one you want.

Ignore this, a new major version is warranted due to introduction of module system, and incompatible jdks.

@hamnis made this comment, but then retracted. Why? Seems like it could work as a separate artifact.

[danicheg]

In a short perspective, bringing a new artifact is worse than doing a new major release. At the moment, we have no plans for a new major release in log4cats (like changing architecture/doing non-binary compatible changes on the whole). So it'd be fine to continue updating several release series, as we do it regularly within Typelevel.
But speaking from the 'real' perspective of updating slf4j in 'real' projects... Users might migrate to Scala 3 earlier than do update the major slf4j version. 😆 So, I'm on the side of bringing the new artifact after some meditation.

[armanbilge]

Just to throw out one more option:

we could schism the log4cats-slf4j integration from this repository, into its own repository. Then it can have independent versioning, and we can bump the major version there without bumping it for core.

[armanbilge]

https://www.slf4j.org/faq.html#compatibility

From the clients perspective, the SLF4J API is backward compatible for all versions. ... To date, binary compatibility in slf4j-api has never been broken.

Honestly to me that just suggests we should pin to 1.x and move on. Anyone who wants to use with 2.x should be able to do so (although may require some build hacking), since it did not break bincompat of the slf4j-api artifact.

[rossabaker]

I haven't seen a compelling argument for libraries to publish for 2.x. Apps that upgrade their backends will evict 1.x to something binary compatible with us, and apps that haven't won't silently break. The worst thing I can imagine by pinning is that we might push SBT eviction warnings downstream.

[rossabaker]

I haven't seen any ill effects of pinning this in multiple downstream libraries. Can we close this as resolved that we stick to 1.x?