cowtowncoder
commented
10 months ago Above sounds like a good plan to me, although granted not being Scala user I cannot fully evaluate it.
On SemVer check: while I think some checking makes sense, I have always felt that it'd be good to have ability to override it with different constructor or factory method, to at least allow "higher" jackson-databind / jackson-core / jackson-annotations versions. But I see how logic could get quite complicated if verifying expected invariants of.
- jackson-annotations >= jackson-databind >= jackson-module-scala
- jackson-core >= jackson-databind >= jackson-module-scala
(wrt minor versions)
pjfanning
Support for Scala 2.10 was dropped shortly before the jackson-module-scala 2.12.0 release (meaning 2.11.4 was last proper release with Scala 2.10 support).
See Release Notes for more context on when changes happened.
I don't intend to fully support Scala 2.10 but am open to doing a jackson-module-scala 2.12.7 release that uses jackson-databind 2.12.7.1. jackson-databind 2.11.4 has 4 CVEs associated with it while 2.12.7.1 has none.
On TideLift, there are appears to be some subscribers who still want jackson-module-scala to support Scala 2.10.
jackson-module-scala is strict about users using a jackson-databind jar that matches the same major-minor version (semver).
https://github.com/FasterXML/jackson-module-scala/tree/2.12-scala_2.10 is the branch where I have experimented with Scala 2.10 support. There is a jackson-module-scala_2.10 2.12.7-SNAPSHOT on OSS Sonatype Snapshots repo.
Do I recommend that jackson-module-scala_2.10 users upgrade to a newer version of jackson-module-scala_2.10? Not really. If you really think upgrading is a good idea, you should probably be looking at getting off Scala 2.10.
You still want to use a newer version of jackson-module-scala_2.10? Then, please test first.