search

FasterXML / jackson-databind

General data-binding package for Jackson (2.x): works on streaming API (core) implementation(s)
Apache License 2.0
3.53k stars 1.38k forks source link

jackson-databind-2.6.1 depends on jackson-annotations-2.6.0 #927

Closed superbob closed 9 years ago

superbob commented 9 years ago

jackson-databind 2.6.1 depends on jackson-annotation 2.6.0. https://github.com/FasterXML/jackson-databind/blob/jackson-databind-2.6.1/pom.xml:

[...]
<!-- Builds on core streaming API; also needs core annotations -->
<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-annotations</artifactId>
  <version>2.6.0</version>
</dependency>
[...]

Shouldn't it be jackson-annotation 2.6.1 (which exists)?

A similar issue was raised with 2.4.4 and 2.4.0 versions (https://github.com/FasterXML/jackson-databind/issues/714).

cowtowncoder commented 9 years ago

No. This is intentional. My personal preference would be to only publish minor (2.6) versions of annotations, as no changes are needed (or permitted) between patches. But majority of developers felt that there is simplicity in using identical full version number across components, and this is why we do actually release patch versions of annotations. But under the hood, these are identical.

So basically:

  1. It does not matter whether it's annotations 2.6.0 or 2.6.1 (or any other 2.6.x), contents are identical.
  2. I prefer to only refer to .0 version of annotations via transitive dependencies.
superbob commented 9 years ago

I see your point. My problem is when using maven, if I want to refer depend on databind 2.6.1 and annotations 2.6.1. I end up having databind 2.6.1, annotations 2.6.1 AND annotaions 2.6.0. So I have to either exclude annotations 2.6.0 from databind 2.6.1 or have 2 different versions (databind 2.6.1 and annotations 2.6.0). So the simplicity you suggest for the developers is not that simple in the end (using maven).

cowtowncoder commented 9 years ago

@superbob It is unfortunate situation, agreed. I wish there was (or, if there is, that I knew of :) ) feature for forcing some sort of unification on transitive dependencies, to prevent bogus incompatibilities. I know there are Maven plugins that report inconsistencies and there may well consider this problematic, despite patch versions being identical (there's no way for plugin to know that).

rnc commented 9 years ago

Is there any plans to reopen this and fix it? i.e. use Maven best practices when releasing artifacts?

cowtowncoder commented 9 years ago

No.

As I have said previously, my preference would have been to drop patch version from annotations, but developer community preferred release of bogus patch versions, to allow for users to use patch-versioned instance of annotations. This enables minor simplification of dependency definitions. So that is what is being done.