Drop patch number from version for 2.20 and later (no more 2.20.0)

[cowtowncoder]

As per discussion jackson-future-ideas#90 (and updated JSTEP-1) we will drop patch release from 2.x series of annotations, due to dropping idea of releasing 3.x versions at all.
Patch number may still be occasionally used if critical problems are found from initial minor release (so we could have 2.20.1 and so on), but no .0 release.

[danielthegray]

Why not change all the Jackson releases consistently? Now we have some Jackson packages being released with the patch ".0" and others without. Our build broke because the 2.20.0 version is not found for jackson-annotations (but was used for all the other packages). jackson-databind is still using 2.20.0.

[cowtowncoder]

@danielthegray I tried to explain reasoning on JSTEP-1 (https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-1) but basically jackson-annotations is special in a few ways.
And with Jackson 3.x continuing to use 2.x annotations (to avoid need for dual annotations) makes use of patch level impractical (no more 1-to-1 mapping).

No other versioning changes like this are planned.
This is one-time hassle: I would strongly recommend use of jackson-bom for consistent version set.

[gaeljw]

I just been hit by this as well. In a sense, it's a good thing as it made me identify projects where Jackson BOM was not used 😅

I guess you can wait for more feedbacks but I would maybe highlight a bit more this change in the release notes or README 🤷🏼‍♂️ As well as encouraging users to use the BOM.

[gaeljw]

For the record, after reading the reasoning behind this change, I initially thought "meh.. we could have kept the patch version even if it's always .0, people are expecting x.y.z" but dropping the patch is actually a (small) signal for users that there's something different with this package and it might help raise awareness.

Still, IMHO this should be highlighted somewhere in the README of main Jackson repo. (Apologies if it's already the case and I missed it!)

[marcrohlfs]

Not sure where I should leave my comment (where it's not just ignored) - and I'd not like to open a 5th (?) issue on this. So, I just duplicate my comment from #307 here. - which actually is an addition to what @gaeljw wrote:

I'm not glad with this versioning difference. This isn't a problem when jackson-annotations is only used as a build dependency via the jackson-bom. But in some places, we need jackson-annotations as plugin dependency, too. And I cannot do a BOM import for plugin dependencies, hence I'd need to configure two Jackson versions (where I used one common property until now). Or am I just not up-to-date with latest Maven features?

[huehnerlady]

If jackson annotations is special, maybe it could also think about your own group id?

We are using group version enforcement to ensure the consistency and with this change we cannot do this anymore as jackson-annotations share the same groupId.

I could imagine other work similar, so maybe that is a way to help with the change being less painful?

[cowtowncoder]

@huehnerlady Reasonable question/suggestion on its own but I think that while this might have made sense if done years ago, at this point it would lead to yet bigger pain, being incompatible with 2.x in even more drastic way, leading to more, not less, pain.

Put another way: different group id would leave to significantly more fragmentation, and essentially completely breaking backwards compatibility for Jackson 2.x.