Please release 2.7.2 ASAP

[odrotbohm]

2.7.1 is quite unusable for us due to the ticket fixed in the hotfix 2.7.1-1. The latter however is even more unusable as the version number is not a valid OSGi one (third digit no number) and we can't go ahead a tweak the build setup for ~20 projects just to upgrade to latest Jackson. Especially if a 2.7.2 is about to be released soon.

I basically want to make obvious that a bugfix release of the 2.7.x branch rather sooner than later is appreciated very much.

[cowtowncoder]

@olivergierke Quick question first on OSGi numbering scheme: I was surprised to hear that this is not valid; I assume it would expect "2.7.1.1" then? So far I have assumed that since Maven has no issues, and since I recall seeing other project use similar naming (which to me is slightly more readable, when fourth digit is only occasionally included, but that's probably matter of taste), this should work just fine.
I can change scheme going forward, I just was not aware of this problem. Thank you for bringing this to my attention.

As to 2.7.2: yes, I hope to release a patch version relatively soon. I was out for vacation last week, but can now go back to see what kind of hot fixes would be good to include. There is one strange test failure for DropWizard, seemingly related to type resolution, that would be great to fix but unfortunately I do not yet have a reproduction outside of DW test suite.

[odrotbohm]

I have to admit I filed the ticket when the issues popped up in building Spring Data, which still produces OSGi metadata using Bundlor. Indeed, the OSGi spec, expects the third digit to be entirely numerical, so the move to 2.7.1-1 would've required me to tweak the build for 15 modules, so I went with 2.7.1.

Moving to 2.7.2 immediately would've prevented this issues. A 2.7.1.1 would've, too, but I can see you don't want to feel like an Oracle database :). I've seen you've been in touch with the core Spring Framework team already and we're going to put some mitigating changes into 4.2 and 4.3, so feel free to just close this one once 2.7.2 is released to.

For Spring Data, we decided to lower our baseline to 2.6.5 again as we're still depending on a minimum of Spring 4.1.9 which is not going to get the mitigation code. That means users will still get Jackson 2.6 for the upcoming Spring Data release out of the box but can upgrade to 2.7 in conjunction with a newer Spring Framework version.

[cowtowncoder]

@olivergierke Ok thank you for the explanation. I think I'll go with "all-dots" notation in future; aesthetics do not trump things actually working...

Going forward, is there a way we could collaborate on checking how Jackson Release Candidates for new minor versions would work? I would love to get better coverage on tests, since while test coverage for "user code" is somewhat wide (if shallow), testing for framework integration has less tests, and is more involved to test. It would be great if smoke testing could be made to avoid some of more obvious problems, before we push .0 out.

The reason why I think it would be great to work more closely with Spring platform is that it is one of the biggest platforms (by users, usage), and also has quite advanced integration needs. So if it is possible to find issues early everyone would benefit.

I hope to release 2.7.2 some time this week or over the weekend. So far there have only been 3 fixes, but there are many more reports so total should be higher in couple of days. Plus that one hot fix from 2.7.1-1 is pretty important too.

[cowtowncoder]

Getting ready to do 2.7.2, but one issue I want to figure out first is #1128 -- I think that may be a nasty problem, and seems very similar to whatever is causing test failures for DropWizard. On plus side I now have unit test to reproduce the problem; on downside I don't yet have an idea of what exactly is going on, beside noticing that some base-class properties are just not being found.

[cowtowncoder]

2.7.2 now released: Scala module hopefully to follow very soon now (as per FasterXML/jackson-module-scala#233).

[odrotbohm]

Thank, Tatu. Much appreciated! Do you release nightly snapshots to some publicly available Maven repository? If so, I'm sure we can set up an integrating build against those to help catching regressions earlier next time.

[cowtowncoder]

@olivergierke We have Travis builds like https://travis-ci.org/FasterXML/jackson-databind if that would work? As usual, open to all suggestion/improvement ideas.

Also: created https://github.com/FasterXML/jackson-jdk6-compat-test for slightly different but perhaps related problem -- would it be possible/useful to create projects for simple integration tests, but so that management of versions to test would be handled by multiple teams. This because development timings differ; I can handle Jackson side, but authors of other libs, frameworks would need to help with their development & versioning aspects.

[odrotbohm]

I just checked the usual suspect repository of Sonatype and could find snapshot builds here. If you can make sure they get updated properly I think we can set up some downstream builds in Spring projects to run Framework functionality on those.

[cowtowncoder]

@olivergierke I think these are fed by Travis builds, as I do not do explicit mvn deploy that often. So I think that is a good source to use.