• 3.0: under development; not expected to be released before Q4 of 2024
• 2.19: about to be started in September 2024

These are branches for which new releases are planned.

• 2.18: open branch (2.18.0 was released in September 2024)
  • Backports accepted for fixes
• 2.17: open branch (2.17.0 was released in March 2024)
  • Backports accepted for fixes
• 2.16: nominally open branch: new releases possible but unlikely
  • Only Critical fix PRs accepted
  • To be closed after 2.19.0 released

These are branches for which new releases are no longer planned: it is possible that in some rare cases micro-patches of components might get released.

• 2.15
  • Closed in September 2024 with release of 2.18.0
• 2.14
  • Closed in November 2023 with release of 2.16.0
• 2.13
  • Closed in November 2023 with release of 2.16.0
  • Last branch where JDK 6 is baseline for streaming jackson-core
  • Last branch for Android SDK 21+ (SDK 26 minimum for 2.14)
• 2.12
  • Closed in 2022/04 when 2.15.0 was released
• 2.11:
  • Closed on 2022/11 when 2.14.0 was released
• 2.10
  • Closed on 2021-09-30 when 2.13.0 was released
• 2.9
  • Closed on 2021-01-06 after release of jackson-databind micro-patch 2.9.10.8
• 2.8
• 2.7
• 2.6
• 2.5
• 2.4
• 2.3
• [2.2]
• [2.1]
• [2.0]

Jackson 1.x branches are not supported: source code can be found from

https://github.com/FasterXML/jackson-1

but there is no currently working mechanism for making new releases (original sources were migrated from Codehaus SVN, build used Ant with Maven task which does not appear to work with Sonatype OSS Nexus any more).

Jackson follows Apache versioning convention, and similar to Semantic Versioning from external user perspective. That is:

1. Major version upgrades (only one so far, 1.x -> 2.x) can include all kinds of changes. However, we do this so that:
   • Neither Java nor Maven package names are reused (that is, we use different packages): this allows different major versions to co-exist
2. Minor version upgrades can contain additions, new methods, and may deprecate existing functionality
   • Our goal is to support all existing public functionality (public methods, constants) with minor versions
   • We do reserve the right to remove deprecated public methods as long as they have existed in deprecated form for at least two minor versions. We try to minimize such removals, but they are nonetheless made in cases where deprecated methods are problematic for future development (can not be supported, or prevent fixing other issues)
3. Patch releases need to fully replaceable and have no changes to source or binary compatibility

Public API in this context means methods and class override mechanism meant for end-users to use. Generally this means public methods and fields, but does not necessarily include all method overrides: that is, sub-classing implementations allows one to use both public and internal APIs. Unfortunately it is difficult to give hard and fast rules on this division, as there are currently no mechanisms to indicate which methods fall into which category.

Further, parts of Internal API are designed to be used by third-party Jackson extension components; both ones developed by Jackson core team (but that are not one of 3 core components) and ones developed by others. It would be good to have specific term for such "semi-public API", but as of now there is no official term.

But the important difference regarding compatibility is:

• Only Public API follows Apache/SemVer versioning.

Internal API -- parts that can be used by extensions modules, but usually NOT called by other application code -- will offer reduced guarantees regarding compatibility. Specifically, the main user-facing guarantee is:

• Extension modules are ONLY guaranteed to work with core components that have same minor version.
  • Jackson team will try to minimize changes that break compatibility, so that it is OFTEN (but not always) possible to use a LATER minor version of core components with an extension module: for example, Joda module version 2.3 with jackson-core and jackson-databind version 2.4.
  • Unfortunately it is not possible to known in advance what the compatibility changes in Internal API are, so it is not possible to define forward-looking rules before actual releases of new minor versions.

So why is there looser definition between Internal than External APIs? Simply because in many cases, extending functionality, and even some of bug fixes require changing of internal call sequences or argument passing. Without allowing for such changes in parts of code that are not end-user facing, we would need to do more frequent full major version upgrades. And since our firm belief is that Major Releases should go with both Maven and Java package name change (to allow for co-existence of different versions) -- belief supported by experience from relatively nice 1.x to 2.x upgrades -- these changes are much more disruptive than minor upgrades.

Having said that, what Jackson team tries to do with regard to Internal APIs is this:

• We will try to maintain Internal API compatibility between ADJACENT Minor Versions, so that extension modules of an earlier minor versions SHOULD be usable with the next minor release of core components.
  • For example, Guava extension module version of 2.3 should be usable with jackson-core and jackson-databind versions of 2.4
  • Note that Jackson core components (annotations, streaming, databind) MUST have same minor version.

So, if you encounter a case where this looser invariant is violated (upgrading of core components to the next minor version breaks extension modules of current minor version), you should report this. We can not guarantee it can be fixed -- there have been cases where unfortunately it is very difficult to make this happen -- but in most cases it is possible.

For full listing of all old releases, check out Old Jackson Wiki. Here are quick links for convenience (note -- for notes on patch versions, go to major version notes, follow links from there)

• 1.x:
  • 1.9
  • 1.8
  • 1.7
  • 1.6
  • 1.5
  • 1.4
  • 1.3
  • 1.2
  • 1.1
  • 1.0