Jackson Releases (original) (raw)

Public releases

NOTE: branching strategy is explained on VERSIONING.md.

Under development

Following versions are under development without official .0 release (but possibly with Release Candidates)

Open branches

Following versions have public releases, and are considered "Open" with possible new patch releases in future.

Closed branches (EOL)

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

Legacy

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

Support

Support available for Jackson versions is explained on Version Support section of main README.md: generally:

General

Jackson follows Apache versioning convention, and is similar to Semantic Versioning from external user perspective (but does not strictly follow the SemVer specification). The full model is documented in VERSIONING.md; in brief:

  1. Major version upgrades (two so far: 1.x -> 2.x, 2.x -> 3.x) can include all kinds of changes. To make this possible, each major version uses different Java packages and Maven groupIds, so that different major versions can co-exist on the same classpath
  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 must be fully replaceable, with no changes to source or binary compatibility

2.20.0 (most) vs 2.20 (jackson-annotations)

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:

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:

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:

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:

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)