Compatibility between jackson-{core,annotations,databind,...} releases

[Wolodja Wentland]

Hi All,

I am currently packaging jackson for Debian and decided to package the various
jackson subprojects as individual projects to reflect upstreams (i.e. your)
split.

It is, however, not entirely clear if I can, for example, use
jackson-annotations 2.2.3 with jackson-core 2.2.2 or any of the other
combinations. I assumed that this is the case as each of these subprojects has
a different release schedule and there is no single X.Y.Z release for all of
them.

This assumption does, however, raise the question how you deal with
compatibility and for which version spans you guarantee it (if at all). I
would hope that it is at least one of:

- X.Y.* (all 2.2.* releases are compatible, I can use jackson-databind
2.2.3 with jackson-core 2.2.2)
- X.* (all 2.* releases are compatible, I can use jackson-databind
2.3 with jackson-core 2.4)

but thought I'd clarify that first. It might also be that you guarantee that
given a topological sorting of dependencies (jackson-core is sorted before
jackson-annotations, ...) that "later" libraries may be newer than earlier
ones.

Thanks for your hard work and may you have a nice day!
--
Wolodja <bab...@gmail.com>

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC

[Tatu Saloranta]

The goal is to follow Apache style semantics:

- Patch versions should be forward and backwards compatible; so any combination of 2.2.x versions (for example) should work. Minus bugs earlier ones may have, fixed later on, of course. So practical recommendation would be "use the latest patch version available".

  * that is, no API changes and functional changes are to be done in patch releases

- Minor versions should be backwards compatible, with respect to application code: you should be able to upgrade from 2.1 to 2.2 without changes to app code. It is still recommended that applications are recompiled if Jackson minor version is upgraded; if there are accidental breakages they should result in compilation errors.

- Major versions -- of which we have two, and there are no plans to introduce third one -- live in different namespaces (packages) and have no interaction; interoperability does not exist.

Beyond this:

- Minor versions of Jackson components should not be mixed: they may work, esp. when using newer version of lower-level components (core of 2.2; data types of 2.1) -- this is not recommended usage. Problem is that while we keep public API as compatible as possible (with deprecation markers), changes to internal/semi-internal interfaces do cause problems between components.

As practical note, we actually do synchronize patch versions currently: 2.2.3 versions of all components are cut at about same time (there may be bit of time fluctuation due to practical reasons)
In future we may skip some releases: for example, there should not be need to do any other 2.3 versions than 2.3.0 for jackson-annotations.
But so far this has not been done; while it could reduce release work for development team it can complicate version handling by users.

Does this make more sense?

-+ Tatu +-

[Wolodja Wentland]

On Thu, Sep 26, 2013 at 10:47 -0700, Tatu Saloranta wrote:
[…]

> Does this make more sense?

Yes, it does and is exactly what I was hoping for as it allows us (i.e.
Debian) to package patch versions for all components independently and as soon
as respective upgrades become available.

At the moment we have packages for jackson 1.* and jackson 2.*, but we haven't
decided yet if you want (or have to) introduce additional packages to track
various minor versions. It would probably be most in line with your
version semantics to have packages for 2.2.*, 2.3.* respectively, but that
depends on our actual needs as well.

Thanks for the clarification!

[Tatu Saloranta]

On Thu, Sep 26, 2013 at 11:17 AM, Wolodja Wentland <bab...@gmail.com> wrote:

On Thu, Sep 26, 2013 at 10:47 -0700, Tatu Saloranta wrote:
[…]

> Does this make more sense?

Yes, it does and is exactly what I was hoping for as it allows us (i.e.
Debian) to package patch versions for all components independently and as soon
as respective upgrades become available.

Ok good.

 

At the moment we have packages for jackson 1.* and jackson 2.*, but we haven't
decided yet if you want (or have to) introduce additional packages to track
various minor versions. It would probably be most in line with your
version semantics to have packages for 2.2.*, 2.3.* respectively, but that
depends on our actual needs as well.

Right, that is a tricky question, and I can see challenges there.

 

Thanks for the clarification!

You are welcome & good luck with packaging!

-+ Tatu +-