logback-access transitive dependency misalignment (in respect to logback-core version)

Dropwizard currently pins logback-core to the 1.5.x line. At the same time, it defines a logback-access-* version of 2.0.15:

<logback.version>1.5.38</logback.version>
<logback.access.version>2.0.15</logback.access.version>

Logback-access 2.0.15's parent artifact (ch.qos.logback.access:parent) wants logback-core 1.6.x:

<logback-core.version>1.6.3</logback-core.version>

Since logback-access's 1.6.x dependency is not being satisfied and if it uses any 1.6-only features, it will die. This seems like a point of concern for causing runtime NoClassDefFoundError, NoSuchMethodError, NoSuchFieldError type crashes on esoteric code paths. To be clear, I have not seen any such crash yet and the tests definitely pass right now. But without exhaustive tests of all transitives (difficult and possibly undesirable to do in any large codebase), it's hard to know with these styles of things.

I do understand logback version upgrades can present a .... stability .... concern. So I'm not saying immediately 'run out and upgrade to logback-core 1.6.x'. But probably we should be looking at the safe way to do that (e.g. sprucing up tests if need be, and then giving it a go?)