On Wed, Sep 28, 2016 at 11:20 AM, 'Michel Krämer' via jackson-user < [email protected]> wrote:
> 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. > Just saying 'semantic versioning; is, unfortunately, not particularly helpful. Not many Java tools pay much attention to alleged semantics; nor is there real criteria of what should be done, if anything, aside from bumping version number. What effect this has really depends on users and downstream libs, frameworks. At least I haven't seen much difference in the way, say, Maven has between having a dep to Jackson 2.9 vs 3.0 (but maybe other build tools have?) I am not against 'simple' major version upgrade, and leaving current Maven / Java package coordinates as is. Perhaps this is the way to go. I just do not think this in itself changes underlying scenario significantly. But let's put it another way: if I was to propose that we go with Jackson 3.0 with Java 8 baseline requirement, would this change anyone's opinion, compared to going with 2.9? Is there any real downside to this? (also note: it is possible that we might just go with Java6 platform compat with 2.9; and go Java 8 after that) -+ Tatu +- > > 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-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.
