microprofile-health: Health 1.1 breaks backwards compatibility with Health 1.0

Issue #125 & PR #127 breaks backwards compatibility with Health 1.0.

The wireformat is part of the spec’s contract, so the health response message body cannot be reconsidered until Health 2.0 is being considered.

Wireformat changes should be reverted, and outcome and state should be restored.

People are already investing in autonomous control planes that respond to MP Health 1.0 /health responses, and MP Health 1.1 cannot break these systems or impose technical debt onto these systems.

I’m not saying 1.1 needs to become 2.0. I’m saying we need to collect our grievances before we cut 2.0, instead of cutting 2.0 with our 1st grievance and 3.0 with our 2nd grievance, etc.

These same versioning constraints should apply to my issue #110 and the unique check names issue #34 and all other issues.

1.1 can have a useless optional “Spring health check ‘outcome/state’ to ‘status/status’ rename compatibility mode”, but 1.1 cannot wholesale change “outcome/state” to “status/status”.

Pushing these changes into 1.1 while be a black eye for MicroProfile as it teaches people that they can’t trust MicroProfile to maintain backwards compatibility.

CC: @Emily-Jiang @cescoffier @antoinesd

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 29 (26 by maintainers)

Most upvoted comments

Hi @derekm. I agree with others that we probably need to bump the version to 2.0 if there are backward compatibility break in 1.1.

Regarding your various remarks, here are a few answers:

MicroProfile was designed to release small and often to avoid tunnel effect we have with Java EE / Jakarta EE. The price for that is to accept (at certain conditions) non backward compatible modification. This said, there’s a common agreement that these should be avoided and introduced if necessary in major version.
Microprofile is a community project. It is supported by major vendors like Red Hat, IBM or others but there’s not a huge team working on it. When it comes to Health Check, no one is full time on it. All this to say that we have a greater need for contributors than advisors.
There’s a Health Check public meeting every 2 weeks. It’s open to everybody in the community. Next meeting will be Friday Oct 26th at 3:00pm CEST on https://zoom.us/j/460194898

antoinesd on Oct 18, 2018

No it doesn’t, that’s what I mean.

Major versions for the umbrella spec are not semantic. If it were, MP umbrella release versioning would increase at a crazy pace.

As per https://docs.google.com/document/d/16v3jVkcDzVz9BVU5aGEzPVbK-a8BIx7S1gbqToVUaLs/edit, MP 2.2 will include new breaking change 2.x versions for Fault Tolerance and Metrics, but MP is only moving from 2.1 to 2.2

kenfinnigan on Oct 19, 2018

I implemented the Vert.x support, and it will be updated as soon as the new MP Health check is released.

cescoffier on Oct 18, 2018

+1 for bumping the version. It’s crucial that MP holds up to backwards compatibility. MP should remain agile but not be seen as experimental.

tnsasse on Oct 18, 2018

The fact this is a breaking change has been discussed on the mailing list. However, I don’t mind releasing it as a 2.0.

cescoffier on Oct 18, 2018