investigate major binary compatibility regressions caused by jackson-databind 2.15.0-rc3-SNAPSHOT
pjfanning opened this issue · 4 comments
See https://github.com/FasterXML/jackson-module-scala/actions/runs/4657473214/jobs/8242103815
- jackson-module-scala tries to maintain binary compatibility between releases and uses a build tool to check for this
- I switched dependency from jackson-databind v2.15.0-rc2 to v2.15.0-rc3-SNAPSHOT and found over 30 new binary compatibility issues relating to code deprecations
- this is not something that I've seen before and I will need to spend time working out what to do
- the issues appear to be because of changes in jackson-databind AnnotationIntrospector or related classes
@cowtowncoder The issue appears to be caused by FasterXML/jackson-databind@7161d21 and there is no need to revert that - I have the build passing now
@pjfanning Ok sorry about that. I had assumed that all modules would have long ago switched not to use those methods -- and also rebuilt core modules. But I forgot that I do not do this for Scala module.
And I should also know better than to start cleanup after second release candidate. In future I will postpone these appropriately.
Thank you for catching this so quickly.
It's not that we use the methods. The build checks for API changes and when we subclass, the build will fail if methods are removed in the super classes. These checks can be configured to ignore certain diffs and I've now done that.
Ok good. Kotlin module does something similar, makes sense.
Might make sense for databind too, although one concern I have is with sheer number of overrides needed for "internal" changes (in theory any change to any protected methods is backwards-incompatible change). The idea is valid tho, it is important to be aware of such changes to avoid accidental removal/change of methods.