Jackson 2: suggestion to not abandon it after Jackson 3 is released but that we mostly fix bugs

[pjfanning]

There is a fairly regular stream of issues reported where use cases that used to work with older versions of Jackson 2 fail with newer versions. There are so many mapper settings and annotation setups that it makes it impossible to test every combination.
My suggestion is that lots of Jackson 2 users have legacy systems that don't need the hassle of trying to get everything working with Jackson 3. Jackson 3 is a big change.
If we continue to issue occasional bug fix releases for Jackson 2 - including any CVE worthy issues fixed in Jackson 3 (if any), I think this would be very useful. I think we should be careful about making behaviour changes to the mapper - no matter how hard the reporters complain. We tend to find that non trivial fixes can as often break stuff for users who depend on the existing behaviour. One person's bug is often someone else's feature. If we do try to make non-trivial fixes, it might be best to add a Feature that allows users to control if the change is applied.
Basically, what I'm suggestion is that we keep Jackson 2 as stable as possible - but still supported for occasional releases with limited changes.
If a new feature is added to Jackson 3, this does not get backported to Jackson 2 and users who want the new feature will need to upgrade to the Jackson 3 ecosystem.

[cowtowncoder]

+1 for carefully considering which new features, or significant improvements, risky fixes target for 2.x: limiting to improve stability.

We definitely need to consider this because there will be significant continued use of 2.x and desires by part of user base to get new features, too.
Intent is not to do what happened to 1.x which is basically abandonement (due to various technical reasons I can't even build 1.x much less ever release). 2.x will be actively maintained for years I think.

[JooHyukKim]

+1 as well.
Thank you for sharing good point @pjfanning

[JooHyukKim]

WDYT about moving target versions of existing "features", not bug, to 3.x in best-effort basis?
We already have tons of features planned in 2.x, with respective target versions, but it would indeed slow down Jackson 3 adoption.
I don't think it not too late to change directions.

And we will still work on stability-related issues in 2.x and forward merge 3.x.
I forgot to raise this issue earlier.

[JooHyukKim]

For example, these two on-going work could be moved to Jackson 3 IMO.

• Fix #3580 Enum (de)serialization in conjunction with JsonFormat.Shape.NUMBER_INT #5333
• Introduce @JsonInclude for Collection #5243

[cowtowncoder]

@JooHyukKim I was about to suggest that... I think both should probably only go against 3.x.
So +1 for that.

... and I need to create 3.0 branch soon, come to think of it.
But 3.x will be for 3.1 when that happens.