Encode Hibernate ORM version into build time enhanced entities
Description
It would be useful for diagnostic purposes to include the version of Hibernate that was used during build time enhancement.
I will not introduce automated checks that rely on this version though as I don't think we should enforce this; a warning about a mismatch would be safer but it risks being too noisy for perfectly adequate situations.
So for now let's just encode the version in there so that power users can use this to verify.
Never mind about my previous comment regarding additional version + checking as that is out of scope for what is described here.
Scott Marlow March 15, 2022 at 1:35 PM
Should there be a separate version for the subset of code responsible for doing build time enhancement? Iām wondering if that would reduce the number of false warnings to only after we have incremented the build-time-version (due to actually changing ORM code that impacts enhancement) and an entity class is detected to already been enhanced with build-time-version < expected-build-time-version.
Do we know when making ORM code changes that entity enhancement is impacted? I suppose the worse case is we forget to increment the build-time-version and notice the mistake later and then release a new ORM + build time enhancer tool.
It would be useful for diagnostic purposes to include the version of Hibernate that was used during build time enhancement.
I will not introduce automated checks that rely on this version though as I don't think we should enforce this; a warning about a mismatch would be safer but it risks being too noisy for perfectly adequate situations.
So for now let's just encode the version in there so that power users can use this to verify.