Repository navigation
Drop patch number from version for 2.20 and later (no more 2.20.0) #294
Description
Activity
- changed the title
[-]Drop patch number from version for 2.20 (no more 2.20.0)[/-][+]Drop patch number from version for 2.20 and later (no more 2.20.0)[/+]on Jul 11, 2025 - added a commit that references this issue
on Jul 11, 2025 - added a commit that references this issue
on Jul 11, 2025 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-databindis still using 2.20.0.Reacted by Tobias Franke, Tom Morris, Fredrik Rubensson, Julian Huff, Anish, Michael Ummels, Ghenadii Batalski, Aditya Bhaskar, CodePlayer, Henning Noeth and 13 more@danielthegray I tried to explain reasoning on JSTEP-1 (https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-1) but basically
jackson-annotationsis 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 ofjackson-bomfor consistent version set.Reacted by Gaël Jourdan-Weil, Ghenadii Batalski and SteveReacted by Victor Williams Stafusa da SilvaI 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.
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 expectingx.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!)
Reacted by Stefan Cordes and Dániel KovácsNot 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?
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?
Reacted by Tobias Franke, nyrygyk, David B., Dániel Kovács and Matthew Read@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.
Reacted by PJ Fanning and Ruth- added a commit that references this issue
on Sep 10, 2025 - added a commit that references this issue
on Sep 15, 2025 - added a commit that references this issue
on Sep 17, 2025
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.1and so on), but no.0release.