com.fasterxml.jackson.core:jackson-databind

Starting with Jackson 2.20, one of components -- jackson-annotations -- is versioned with just "major.minor" version, with NO PATCH version (in normal cases). See JSTEP-1 for explanation of this difference.

NOTE: before 2.20, jackson-annotations versions did use patch level as well -- but all variations were identical (no changes in patch releases).

Public vs Internal APIs

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 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 know 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.

Long-Term Support (LTS) versions

As defined by JSTEP-13 , Jackson versioning adopted LTS concept similar to how JDK handles versions. Basically:

• At most one non-LTS version branch (per major version) is kept open: the "Latest Release" branch

• Since 2.18 was designated LTS, branch 2.19 (non-LTS) was kept open once released, but closed when 2.20.0 (non-LTS) was released; 2.20 branch in turn was closed when 2.21(.0) (LTS) was released

• LTS (or non-LTS) designation is determined at time of initial .0 (like, 2.21.0) release.

• Typically every 3rd minor version is designated as LTS, but this is not a rule; it is based on timing and general contents of releases (more experimental changes ideally going in NON-LTS versions).

• LTS versions are kept open for minimum of 2 years (rounded up to quarter, typically)

Older releases (from Old Jackson Wiki)

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

Clone this wiki locally

You can’t perform that action at this time.