Back to JSTEP page)

Long-Term Support (LTS) branches, versions

Author

Tatu Saloranta (@cowtowncoder)

Version history

• 2025-06-04: Suggest choosing 2.18 as the first 2.x LTS (not 2.15)
• 2025-04-22: Created first proposal

Status

Initial discussions, see #84.

Current Approach (Jackson 2.x)

When releasing official "dot-oh" minor version like 2.18.0, we create a new branch for the next minor version development: 2.19. Older branches are supported in "train" style: last N minor versions are kept officially open with no "gaps" (meaning: if 2.16 and 2.18 are open, 2.17 must be open too).

"Open" means that:

1. Some bug fixes are back-ported into older Open versions: which ones get merged and where is on case-by-case basis.
2. Patch releases are made from older Open versions loosely based on accumulation of fixes (but sometimes based on criticality of specific fix(es)).
3. All fixes are merged forward from the oldest backport -- so if, for example, if we are working on 2.19 pre-2.19.0, and have 2.16, 2.17 and 2.18 open, we might backport a simple/safe fix to 2.17, merge forward into 2.18 and 2.19. This is done by either fixing in the oldest target branch or cherry-picking from current to target. Expected ease of merging and relatively risk are used to decide which of the open branches is the target branch.

Formerly open branches are closed in FIFO order: the oldest open branch is always closed first. Closing of a branch is usually due to release of a new "dot-oh" minor version -- so, for example, since at this point 2.16 is the oldest open branch, when 2.19.0 is released, 2.16 branch will likely be closed (2.17 might be too, or might be not).

List of open branches can be found here: https://github.com/FasterXML/jackson/wiki/Jackson-Releases

Challenges for users

While relatively simple scheme ("last N minor version branches open, releases made from; oldest one typically closed when new '.0' release occurs'), there are some problems for users.

Support time for given minor version unpredictable ("how long is 2.17 supported?")

When users decide to upgrade to a minor version, or contemplate doing so, it would be good to know how long given minor version will be supported ("open"). But which our current scheme the decision to close is indirect and mostly relies on speed at which newer minor versions are released. Decision on closing is also optimized for maintainers preferences -- there are benefits from not having to make releases from old branches (each full release taking 3-4 hours of time).

Maximum support time more limited with "last N" approach

If set of supported branches was allowed to be non-contiguous -- say, 3 open versions were not 2.16, 2.17 and 2.18 but, say, 2.10, 2.15, 2.18 -- then the support time for the oldest version (2.10) would be much longer. This would not necessarily increase number of releases that need to be made since there are still only 3 open branches in both cases. It might increase effort needed to backport fixes to some degree, but overall should not lead to significant maintenance effort increase.

Proposed change: add Long-Term Support designation, with closing rules, possible EOS dates

So, the first thing is that each new minor version can be designed as a Long-Term Support(ed) version: typically at .0 release, but potentially later on -- however, only when it is the last minor version release. Once a branch/version is designated as LTS, it would remain so. Typically we would designate every 3rd minor version as an LTS.

LTS branches would be closed similar to the current scheme, in FIFO fashion. We may choose to commit to (earliest) EOS (End-of-Support) dates -- meaning that an LTS branch is guaranteed to remain open until specified date (but may remain open longer).

Only LTS branches and the latest branch with release are open: if the latest released branch -- currently 2.18 -- is not designated as LTS, and a new .0 version -- 2.19.0 as of now -- is released, the formerly latest branch (2.18) will be always closed (although possibly after making one more release).

Proposed EOS timeline: 2 year default/minimum

Suggested default End-of-Support timeline is 2 years since the initial .0 release. For practical purposes it should be rounded up to end of that calendar quarter: for example, if 2.19.0 was released on April 24, 2025, suggested End-of-Support date would be June 30, 2027.

Jackson 2.x vs 3.x: separate LTS designations

Once Jackson 3.0.0 is released, we will have 2 parallel version streams: 2.x and 3.x. They would both have their own set of LTS and non-LTS branches. We will still merge fixes up from 2.x to 3.x, deciding on forward-merging wrt open 3.x branches on case-by-case basis.

Proposed initial LTS designations

Jackson 2.x: 2.18 (or 2.15?)

Although the oldest open branch is 2.16, the best candidate for LTS version is probably the current head, 2.18: this is the version in which Bean Property Introspection was included, so it should work as the stable base. JDK baseline was last increased in 2.14 and supporting 2.13 would be difficult due to it being closed for 2 years. One concern would closing of 2.16 and 2.17 branches, causing initial bump into oldest supported version.

The main alternative would be to designate 2.15 AND 2.18 as LTS versions (requiring re-opening of 2.15). This would significantly increase theoretical length of support period for oldest Jackson version.

Secondary question is whether there should be EOL date for 2.18 (and/or 2.15 if also designated).

• 2.18.0 released in September 2024: EOL at... end of 2026? (for 2.5 years lifetime)
• 2.15.0 released in April 2023: EOL of April 2026 would give total span of 3 years.

Proposal: 2.18

Due to change in publishing (Sonatype deprecating and soon closing down their OSSRH Nexus), 2.18 is the oldest branch that can be successfully published. Although it would be possible to make similar changes to 2.15, it seems better to select 2.18 as "modern" first LTS version.

Jackson 3.x: 3.0

Since no release yet made, it seems reasonably to start with 3.0 as an LTS version.