Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check for minimum compatible Hibernate ORM version during bootstrap #1796

Open
Sanne opened this issue Nov 23, 2023 · 0 comments
Open

Check for minimum compatible Hibernate ORM version during bootstrap #1796

Sanne opened this issue Nov 23, 2023 · 0 comments
Assignees
Labels
problem A limitation or source of discomfort

Comments

@Sanne
Copy link
Member

Sanne commented Nov 23, 2023

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.

@Sanne Sanne added the problem A limitation or source of discomfort label Nov 23, 2023
@DavideD DavideD self-assigned this Nov 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
problem A limitation or source of discomfort
Projects
None yet
Development

No branches or pull requests

2 participants