Upgrade to Jackson 2.13.2.1

[snicoll]

No description provided.

[breun]

• Spring Boot Dependencies 2.6.6 manages jackson-bom.version at version 2.13.2.20220328, which manages jackson.version.databind at version 2.13.2.2.
• Spring Boot Dependencies 2.6.7 manages jackson-bom.version at version 2.13.2.1, which manages jackson.version.databind at version 2.13.2.1.

So, upgrading from Spring Boot 2.6.6 to 2.6.7 results in a downgrade from Jackson Databind 2.13.2.2 to 2.13.2.1. Is this intentional?

[snicoll]

@breun as indicated on the commit (where you've commented the same thing too), the jackson bom in 2.6.7 is more recent than the jackson bom in 2.6.6. If there is an issue with the content of the new bom, you're asking in the wrong place as we're not managing it.

[breun]

jackson-bom 2.13.2.1 was released at a later date than 2.13.2.20220328, but doesn't seem to have more recent contents and also doesn't have a higher version number, so that's why I'm wondering if this change should have been applied.

Reading FasterXML/jackson-bom#52 it seems jackson-bom 2.13.2.1 was released because of some Gradle metadata issue with jackson-bom 2.13.2.20220328. I'm not a Gradle user and I don't really understand the issue, and if it would impact Spring Boot users, but it does result in a downgrade of Jackson Databind from 2.13.2.2 to 2.13.2.1 for Spring Boot users upgrading from 2.6.6 to 2.6.7.

[breun]

I know Spring Boot is not managing the contents of the jackson-bom, but it does manage the version of jackson-bom used in Spring Boot projects. Shouldn't Spring Boot manage the highest compatible version (2.13.2.20220328 from March 28) instead of the compatible version with the latest release date (2.13.2.1 from March 29)? Maybe this is a flaw in Spring Boot's dependency update logic?

[wilkinsona]

@breun 2.13.2.1 is the latest and greatest version of Jackson's bom. Jackson Databind 2.13.2.2 and 2.13.2.1 are functionally identical. The Gradle Module Metadata (GMM) in 2.13.2.1 accidentally referenced Jackson Bom 2.13.2.1 which did not exist. This was originally fixed by released 2.13.2.2 with updated GMM and no other changes. @cowtowncoder subsequently reconsidered this and decided to release Jackson Bom 2.13.2.1 so that Jackson Databind 2.13.2.1 would just work.

As @snicoll said above, if you disagree with the latest and greatest Jackson 2.13 bom referencing Jackson Databind 2.13.2.1 rather than 2.13.2.2, please raise it in the appropriate place.

[breun]

It think it's quite confusing that 2.13.2.1 is considered greater than 2.13.2.20220328 (both Maven's artifact version comparison and Renovate don't consider that to be the case), and that a more recent version of the BOM provides an older version of Jackson Databind, but I guess Spring Boot indeed can't help that. And if Jackson Databind 2.13.2.1 is just as safe as 2.13.2.2, then I've also got a security scanner to convince. Anyway, thanks for the explanation.

[breun]

@cowtowncoder (FasterXML/jackson-bom#52 (comment)):

Ok, right. Semantically, I would NOT consider 2.13.2.1 bom to be newer or later -- it was released only to work around the flaw in release of jackson-databind 2.13.2.1, after the fact. Normally all micro-patch BOMs have datestamp instead of fourth digit; this since there is no consistent set of micro-patches (different components may have different 4th digit, including none at all for most of them).
Not 100% sure why Spring Boot chose 2.13.2.1 but yes, it should be equivalent to the alternatives.

Once we release 2.13.3 this will all be untangled but that may take a while yet.

[wilkinsona]

Thanks, @breun. That's quite unfortunate. Our next releases are in mid-May. We could consider flipping back to 2.13.2.20220328 but it's tempting to avoid that churn by just waiting for 2.13.3. It may even be out by then in which case the problem will resolve itself. Let's see what the next month brings.