JSTEP-13: Jackson LTS branches/versions? (2.18, 2.21, 3.1)

[cowtowncoder]

I just created https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-13 to propose adding concept of "Long-Term Support[ed]" branches/versions. The basic idea is to borrow LTS concept from JDK and consider changing set of "open" (~= supported versions) from "last N minor version [branche]s" into "last minor version branch plus 2 or 3 specific ones designated as LTS".

The benefit here would be for users to be able to make more informed decision on which minor versions to upgrade to -- especially if we also decided on EOL dates for LTS versions at the time of designation.

WDYT?

EDIT

Initial LTS versions decided as:

• 2.18 -- oldest releasable pre-3.x, first version with re-written property introspection, stable.
• 2.21 -- first 2.x minor version released after 3.0.0 GA release
• 3.1 -- with bug fixes in 3.0.x, hoped to be more stable.

[cowtowncoder]

/cc @JooHyukKim @pjfanning @yawkat @k163377 @sdeleuze @stevenschlansker

[JooHyukKim]

Seems like good idea. Especially from users' perspective who would be using LTS from frameworks like spring or quarks.

[cowtowncoder]

Yes, we could and should collaborate with framework maintainers (hi @sdeleuze :) ) in deciding on LTS status, should we proceed with this idea.

[stevenschlansker]

Thanks for asking us for input. Personally, we try to track the latest release as close as possible - unless there is a change that affects e.g. JAX-RS integration (rare? never?) we're pretty quick to upgrade and wouldn't really use LTS ourselves :)

[cowtowncoder]

@stevenschlansker This is good info as well, thanks! There will always be one "latest" branch open for updates (like 2.18 right now) so this should not affect early adopters a lot I think.

[cowtowncoder]

NOTE: now that Sonatype publishing has moved to Central Portal, and I have retrofitted 2.18, 2.19 and 2.x branches (3.x already worked since "tools.jackson" namespace moved earlier), it seems like starting LTSes with 2.18 makes most sense.

[JooHyukKim]

Just simple idea, for simpler operational approach.
Aligns with discussion we had in #94

Proposal : Jackson “2.20-Only” LTS

Jackson 2.20 would serve as the ONLY official LTS for the 2.x line, and the latest minor branch

Rational

Instead of juggling multiple open branches/versions, the idea is to give the community and maintainers one stable base for long-term support while keeping the door open for innovation and faster iteration on newer Jackson 3 version.

This means significant bug fixes and security patches could be backported to single 2.20 version as needed. Not to mutiple LTS versions.

This setup makes it obvious for users:

• If you need stability, stay on 2.20.x.
• If you want new features, move to newer 2.x or 3.x versions.

This simplifies maintenance work — no forward merges, no parallel branch juggling, and no uncertainty about which version is considered stable.

Considerations

• (Question) Would there be any reason we are forced to choose no other than newer branch? If none, fine with suggestion here.

[pjfanning]

One option would be to remove the 2.20 branch and change the version setting in 2.x to 2.20.1-SNAPSHOT. It's possible we might occasionally release 2.21.0 style minor releases if we had to make non-trivial changes. The expectation would be that this would be fairly unlikely.
Having 2.x and 3.x as the Dev branches seems consistent.

[cowtowncoder]

One immediate challenge: I don't think we can actually stop 2.x train if and when we need new versions of jackson-annotations for use by newer 3.x versions.

I am also not sure we want to quite yet stop minor non-patch changes in 2.x branch. So rolling back 2.x to 2.20 is probably no-go.

But we can and should be careful about 2.x line of versions.

[cowtowncoder]

Ok in practical terms: I think:

• 2.18 should be an LTS
• 2.20 was released "early" due to jackson-annotations needing to be released for J 3.0.0 to use
• I expect some minor-level fixes for 2.x, for smoother 2.x/3.x migration support. So probably 2.21 relatively soon (but we'll see)
• Maybe 2.21 should be LTS and also "slow down" version?

[JooHyukKim]

So I expect that 2.21 will be released as the next LTS

What is the reasoning behind this? Just asking out of curiosity.

[JooHyukKim]

(IMHO I would not have made 2.18 an LTS but just 2.21 - less work)

One less LTS is sure less work , but there has been a set of modifications needed care so...

[pjfanning]

It's too late to say 2.18 is not LTS but there is reasonable justification to say 2.21 is LTS too. Maybe after declaring a new 2.x LTS, we could declare that 2.18 LTS ends after a year or something like that.

[cowtowncoder]

Yes, my thinking is that both 2.18 and 2.21 should be LTS versions.

Note, too, that choice of LTS is meant to help users plan their dependencies, not necessarily to minimize maintenance burden. And there is no requirement (or implied assumption) that, say, we'd want to always backport all 2.x fixes into all open LTSes. It's more that non-LTS versions get fully closed earlier and LTS backports are at least considered on case-by-case basis.

As to why 2.18:

• It is the first version after Property Introspection rewrite (new baseline wrt introspection, many important fixes)
• It is the oldest version from which publishing converted to use Sonatype Central
• Due to timing seemed like the obvious choice.

[cowtowncoder]

One note: usually we should declare lifespan of LTS at the time of .0 -- this to give users expectations of when to expect end-of-support. It is challenging thing to do with non-corporate software with little Project/Product management capacity (or desire for) but doable.

[cowtowncoder]

Quick note: for 3.x, I propose:

• 3.0 was not designated LTS initially, and should not be promoted into one: it is transitional
• 3.1 should be the first LTS version in 3.x.
  • Many fixes, and will have one non-trivial behavioral change for 3.x line.

[sdeleuze]

@cowtowncoder Could you please confirm that 3.1 and 2.21 LTS releases will share the same jackson-annotations version?

[pjfanning]

Yes they will. 2.21

[cowtowncoder]

Like @pjfanning said, yes.

[cowtowncoder]

Ok: to close the loop here (and to update JSTEP-13 definition): I propose:

1. Initial LTS versions decided on: 2.18, 2.21, 3.1 (just stating the fact)
2. Minimum (and likely also actual) lifetime -- time branch open from .0 to closing (and usually one last patch release) -- defined as 2 years.
   • It is possible there is no "extra" last patch if no fixes accumulated since last one, so time span from, say, 2.18.0 to 2.18.N (last patch) may be less than 2 years
   • Closing of LTS versions not necessarily synchronized across versions but in practice is likely to be so (i.e. starting new 3.x LTS may occur at time of closing oldest open 3.x LTS; but need not be)
3. LTS designation made before or at the first (.0) release from branch

Anyone against this?

@JooHyukKim @pjfanning @yawkat @k163377 @sdeleuze

[JooHyukKim]

LGTM overall.

Jjust a small thought on the 3.0 / 3.1 LTS thing tho -- Since 3.0 is being positioned as "transitional" (not LTS), it might be worth
adding a short note somewhere visible — maybe in JSTEP-13 or the migration guide — that nudges 3.0 users toward 3.1.

Something like:

⚠️ 3.0 is not an LTS version. If you're on 3.x, 3.1 is your target for LTS support.

People who jumped on 3.0 early might not naturally realize they're on a
non-LTS track. A one-liner like this could save a lot of confusion down the road.

Happy to help draft it if that'd be useful!

[sdeleuze]

LGTM

[cowtowncoder]

@JooHyukKim +1 for that idea.

[JooHyukKim]

Wrote PR FasterXML/jackson#351 !