Ok some updates. On Tue, Aug 4, 2020 at 9:18 PM Tatu Saloranta <t...@fasterxml.com> wrote: > > Since I am going for a brief vacation, I thought I might send a quick > update on my plan for getting Jackson 2.12 ready for release. > My todo wiki page: > > https://github.com/FasterXML/jackson-future-ideas/wiki/Jackson-Work-in-Progress > > should be quite up-to-date and show specific things I plan to tackle. > > The goal for 2.12 minor version was to combine the shorter development > cycle of 2.11 (about 6 months) with more ambitious features of 2.10 > (took 2 years), specifically targeting "most wanted" features. > No changes are planned for JDK baseline or dependencies. > > The Big features I think should be included in 2.12 include: > > 1. Ability to configure datatype coercions (implicit conversions in > case where JSON type does not have obvious natural mapping) > (https://github.com/FasterXML/jackson-databind/issues/2113) > 2. Much improved XML module (duplicate-preserving `JsonNode`, mixed > content, fix most existing bugs) (multiple issues) > 3. `@JsonIncludeProperties`! > (https://github.com/FasterXML/jackson-databind/issues/1296) > 4. Improved 1-argument Creator detection > (https://github.com/FasterXML/jackson-databind/issues/1498) > 5. Java 14 Record support > > Of these, first three are complete: "CoercionConfig" and much improved > `jackson-dataformat-xml` were rather large undertakings (and former > requires more work to support by datatype modules); fortunately > Baptiste send an impressive PR to implement `@JsonIncludeProperties`. > > This leaves last two items: for #5 there is a PR and I just need time > to think through smaller details, but the basic idea is sound. > And then I have to focus on getting #4 done: after > `@JsonIncludeProperties` it is probably the oldest "most wanted" issue > around, and while the "big introspection rewrite" is still planned for > Jackson 3.0, this should help with one specific edge case.
At this point #5 -- Java 14 Record support is complete and assumed working. I am now working on #4, adding interface/API, having implemented parts of the feature. Hoping to complete by the end of this week, which would allow RC by end of September. This leads to one practical question: naming of the first (and possibly only) Release Candidate. 2.11.0.rc1 went smoothly and was useful in finding a couple of defects, which was an encouraging result compared to earlier RCs where there was less feedback. But it uncovered one problem: while use of "rc" over "pr" was a good change (former is handled by systems that are aware of qualifiers; latter not), there seems to be a fundamental problem with separator for last part, so that: 1. "2.11.0.rc1" is NOT recognized as special non-production by some systems (esp. ones relying on strict SemVeer) -- most importantly, Tidelift (libraries.io) considers this a "real" release, which is unfortunate 2. "2.11.0-rc1" WOULD BE recognized by Tidelift et al but apparently DOES NOT work as version for OSGi It is possible there could be some magic to let "2.12.0-rc1" be used as Maven version but translate it into "2.12.0.rc1" for OSGi Manifest: if anyone has ideas of how to make Maven build do that I am all ears. But assuming that there is a choice to be made here where something has to give, I am leaning towards sacrificing OSGi compatibility of Release Candidates (real published versions still working, of course), Tidelift being a backer of Jackson project (and my having to do more metadata maintenance work if qualifier isn't recognized). So: my current plan is to change versioning to use 2.12.0-rc1 as the Release Candidate version for Maven release. I am open to suggestions here and thought I'll share the current situation -+ Tatu +- -- 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 jackson-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAL4a10gSy6XQWYG%3Dv3%3D_Erc2kAsL2WjkvMfrc65GXmWPjFZ9Kg%40mail.gmail.com.
