2.9.x Breaks Backwards Compatibility - Multiple Issues Reported

[EarthCitizen]

Reviewing the issues there are multiple cases of 2.9.x breaking backwards compatibility with 2.8 and previous:

#2147
#2134
#2111
#2136
#2100

2.9 should, by contract of semantic versioning, have backwards compatibility with all previous minor versions.

According to https://semver.org, minor version changes should:

MINOR version when you add functionality in a backwards-compatible manner

[cowtowncoder]

(note: edited)

It would be better to discuss compatibility issues on mailing list, since keeping backwards compatibility is rather complicated business. It is impractical (if not impossible) to fully guarantee backwards compatibility of all theoretical interfaces (that is, all methods, fields that user may call just based on Java visibility rules), without introducing breaking major changes for practically all versions that users would deem minor versions (see Guava's challenges as example). Yet it is important to set guidelines on which class interfaces form Public API, which SHOULD be guaranteed by strict SemVer rules; and then other parts of more or less internal interfaces where less strict guarantees are provided.

[EarthCitizen]

I may be overlooking that, but where would I find the information on those mailing lists? I don't see it in neither the README nor the project wiki.

Thanks

[cowtowncoder]

I should update README here to point to Jackson portal page which has the info (thanks!); dev list would be:

https://groups.google.com/forum/#!forum/jackson-dev

I'll also try to see if I can something I wrote about challenges wrt SemVer, regarding differences between public API (calls for app devs to make), semi-public API (extension points for modules), intended private (possible extension points not supported) and private API. I think that there should be some way to indicate which parts of interfaces are which, but as-is it is difficult for users and developers to know this.
This on top of accidental changes to functionality causes much frustration to users and it would be great to work on both reducing changes (ideally eliminating public API changes, as per SemVer) and documenting places where lower guarantees are used (for example, non-public interfaces that can be used via sub-classing must be deprecated, kept for at least one minor version, which is the unofficial guideline).