First of all, let me say that I second the idea to upgrade to Java 8. It offers so many possibilities, and Java 7 is EOL since April 2015 anyhow. However, I understand the need for support for older Java versions. This is something that definitely needs to be discussed in depth.
> But more useful were comments; especially one by Olivier G, who suggested > that this is a Major change, and should be reflected by changing version to > Jackson 3.0. Is there a specific reason why Jackson is not following the semantic versioning scheme? If it was, the decision would be very easy. A breaking change would mean the major version has to be increased. IMHO requiring a newer Java version is a breaking change so I would recommend to go to 3.0.0 (as it would be with semantic versioning) just as Oliver G suggested. I hope this helps. Michel > On 28 Sep 2016, at 19:11, Tatu Saloranta <[email protected]> wrote: > > Some further thoughts on this. > > I did a poll on Twitter, with results of: > > * 89%: Go with Java8 > * 11%: Stick to Java6 runtime compatibility > > (with 57 answers). > > which sort of confirmed my hunch on what the general feeling would be. This > in itself wasn't news, but at least provided some support for some desire of > backwards compatibility. > > But more useful were comments; especially one by Olivier G, who suggested > that this is a Major change, and should be reflected by changing version to > Jackson 3.0. > > My gut reaction was "hell no!", but I started meta-thinking as to why so. > This lead back to Jackson 1.9 -> 2.0 upgrade, and how that was done; I > realized that I feel strongly that this is not what should be done now. > The problem here is that while I consider Jackson 1.x -> 2.0 upgrade a > success in many way -- it has avoided some of nastiest compatibility problems > due to namespacing -- it has lead to fragmentation, such that perhaps 1/4 or > 1/3 of all Jackson usage is still with old Jackson 1.x, which hasn't been > maintained for years. But at least with 2.0, there were many things I wanted > to change in API, some in behavior, so that such abrupt change had certain > benefits. I do not feel we are in same situation with 2.x yet. > Further, fragmenting usage once more would in all likelihood result in even > slower adoption of Jackson 3. > > However. Doing 3.0 the way 2.0 was done. Many libraries do very little in way > of changes, and "major" version upgrade is more of a "Marketing Major", > chosen to imply something totally new and better, but with little to no > compatibility change. > I tend to dislike this approach in general, but in this particular case > perhaps it would be a reasonable thing to do: while API itself is compatible > (at level of regular minor version upgdade), platform requirements are > different, so from user perspective change may be big -- it is trivial, if > already on Java 8, but major if not. > > So.... there's this possibility, that we would boost major version, but NOT > change either Maven group id or Java package name(s). > We could make some other slightly more breaking changes to things like > defaults; and removal of deprecated parts of public API (instead of only > internal APIs, from which deprecated methods are and will be removed over > time, even in minor releases). > But for the most part we'd have to minimize compatibility changes, since > there would be no namespace isolation. > > WDYT? > > -+ Tatu +- > > > > On Mon, Sep 26, 2016 at 9:32 PM, Tatu Saloranta <[email protected]> wrote: > After slow gradual upgrades to JDK baseline, I think time may have come to > move to Java 8 for Jackson 2.9. But before committing to this course, I want > to make sure there is wide agreement on this, as well as on mitigation plans > for users who can not use the new version. > > My thinking here is that moving to Java 8 is mostly beneficial, first, in > simplifying use of 3 commonly used add-on modules: > > 1. jackson-module-parameter-names: Small modules that allows introspection of > creator (constructor, static factory method) parameter names. Easy to just > embed > 2. jackson-datatype-jdk8: Optional and related types. Medium-size, probably > easiest to just directly embed > 3. jackson-datatype-jsr310: Java 8 date/time -- big module, need to figure > out if to embed, or to add dependency + auto-registration > > Use of Java 8 language features would also be nice but I am not yet sure how > to proceed with API changes. It may make sense to first add support for JDK 8 > types, and then target API improvements (and implementation usage) for later. > > If this change is made, I think we would want to keep 2.8 branch open for > longer than most other minor branches. > This would probably be most relevant for Android (as usual :), although we > could also consider advocating use of jackson-jr more as an alternative that > has some benefits for Android as well -- and it will remain Java 6 compatible > for foreseeable future. > I have also read articles about Android moving towards Java 8 as well so > maybe it's just a question of timing. > > At any rate: first things first -- anyone against raising Jackson 2.9 > baseline to be Java 8? (if not, there are follow-up aspects to discuss, esp. > wrt Java 8 datatype module). > > -+ Tatu +- > > > > -- > You received this message because you are subscribed to the Google Groups > "jackson-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "jackson-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
