Better story for library version compatibility

[gmethvin]

At the moment we introduce breaking library changes in patch versions, which can create pretty significant disruption for users. It's great to keep libraries up to date, but if pulsar4s upgrades a library (e.g. play-json or Akka) when upgrading to a patch version that's means I either need to upgrade the library or risk binary incompatibility issues in my project. It seems like we might need different branches for different library versions, and/or a more conservative approach to upgrading libraries.

[sksamuel]

Maybe we can be more conservative by saying we only upgrade a dependency by patch version for any given minor version ? In other words for 2.4.x we only update other deps by patch once 2.4.0 dropped.

…

On Tue, 14 Jan 2020 at 16:57, Greg Methvin ***@***.***> wrote: At the moment we introduce breaking library changes in patch versions, which can create pretty significant disruption for users. It's great to keep libraries up to date, but if I have to upgrade a library (e.g. play-json or Akka) when upgrading to a patch version that's means I either need to upgrade the library or risk binary incompatibility issues in my project. It seems like we might need different branches for different library versions, and/or a more conservative approach to upgrading libraries. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#127>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVSGTV55XMLI53ATDAR33Q5Y7NZANCNFSM4KG22Z3A> .

[gmethvin]

I actually think we can be more conservative than that if possible. For example Akka 2.6.x is backwards compatible with 2.5.x (assuming no use of deprecated APIs). So if we continue to depend on 2.5.x, our library will work for both 2.5.x and 2.6.x users, but if we upgrade to 2.6.x, we're cutting off Akka 2.5.x users for no good reason. There's no reason for pulsar4s to upgrade its Akka to 2.6.x until we need to make use of Akka 2.6.x features.

[sksamuel]

Agreed.

…

On Thu, 23 Jan 2020 at 20:43, Greg Methvin ***@***.***> wrote: I actually think we can be more conservative than that if possible. For example Akka 2.6.x is backwards compatible with 2.5.x (assuming no use of deprecated APIs). So if we continue to depend on 2.5.x, our library will work for both 2.5.x and 2.6.x users, but if we upgrade to 2.6.x, we're cutting off Akka 2.5.x users for no good reason. There's no reason for pulsar4s to upgrade its Akka to 2.6.x until we need to make use of Akka 2.6.x features. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#127>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVSGURD4KYUB2VSY6AUIDQ7JITNANCNFSM4KG22Z3A> .