You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Triaging recent bug reports, it seems like some people made some mistake in BOM cocktails ending up to pick a micro of Hibernate ORM slightly behind the version expected by Hibernate Reactive.
This is their "fault" but the impact is problematic, as this might cause problems at runtime which aren't spotted early enough - and might even elude integration tests and only be identified when specific circumstances are hit. We need to fail fast, and improve the error messages.
[ This brings back memories of when the Hibernate Search SPI integration wasn't as stable, or when OGM would - similarly to Reactive today - bind to ORM in a highly coupled way. We had many users getting burned by occasional misalignement - and I remember discussing with some of you if we should be having some version-checks based on manifests right during bootstrap ]
We want to retain some flexibility: when a new version of Hibernate ORM is released which doesn't strictly require changes on the Hibernate Reactive side - and hopefully this will be more and more likely as the two projects stabilize their integration - we shouldn't require an Hibernate Reactive release just to update the range of compatible versions. So while not perfectly covering all cases, I would check for a specified minimal ORM version.
As the ORM CI pipeline evolves it will be less likely to push a release out which breaks Hibernate Reactive compatibility, however we also need to allow for such releases to occasionally happen (e.g. a new major change, but not exclusively) - this might imply having some metadata on the ORM side explicitly listing a minimal version of Hibernate Reactive as well, which we could change on the ORM side when intentionally/knowingly breaking things, however this would create a bi-directional maintenance burden and I feel we'd be overcomplicating this problem: let's just check from the HR side, for now, and see if it's a good balance.
The text was updated successfully, but these errors were encountered:
Triaging recent bug reports, it seems like some people made some mistake in BOM cocktails ending up to pick a micro of Hibernate ORM slightly behind the version expected by Hibernate Reactive.
This is their "fault" but the impact is problematic, as this might cause problems at runtime which aren't spotted early enough - and might even elude integration tests and only be identified when specific circumstances are hit. We need to fail fast, and improve the error messages.
[ This brings back memories of when the Hibernate Search SPI integration wasn't as stable, or when OGM would - similarly to Reactive today - bind to ORM in a highly coupled way. We had many users getting burned by occasional misalignement - and I remember discussing with some of you if we should be having some version-checks based on manifests right during bootstrap ]
We want to retain some flexibility: when a new version of Hibernate ORM is released which doesn't strictly require changes on the Hibernate Reactive side - and hopefully this will be more and more likely as the two projects stabilize their integration - we shouldn't require an Hibernate Reactive release just to update the range of compatible versions. So while not perfectly covering all cases, I would check for a specified minimal ORM version.
As the ORM CI pipeline evolves it will be less likely to push a release out which breaks Hibernate Reactive compatibility, however we also need to allow for such releases to occasionally happen (e.g. a new major change, but not exclusively) - this might imply having some metadata on the ORM side explicitly listing a minimal version of Hibernate Reactive as well, which we could change on the ORM side when intentionally/knowingly breaking things, however this would create a bi-directional maintenance burden and I feel we'd be overcomplicating this problem: let's just check from the HR side, for now, and see if it's a good balance.
The text was updated successfully, but these errors were encountered: