[hibernate-dev] Hibernate ORM modules published as major.minor and an alias for main

[Sanne Grinovero]

On 15 January 2015 at 16:01, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> On 15 Jan 2015, at 16:54, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> The part that I am unsure about is including the micro version in the module
> path, which means that every release of WildFly that includes an upgraded
> Hibernate, will likely have the jars in a different path (could be a pain
> for any configuration settings that point to the Hibernate jars).
>
> The actual module path would also move around a lot in git, which is
> annoying but I have no real complaints about that.
>
>
> On that I am neutral. I remember Sanne advocated this but I forgot the
> rational nor if I was convinced ;)

Uhm it's annoying that the file would move in git indeed. But is that
a requirement of the modules system or is that a convention which we
could challenge/refine?

For technical reasons it's obviously better to be able to pick a
specific version than not being able to; for example OGM requires a
specific version of ORM, and "4.3" is not good enough to make sure
we're using the right one. The current solution is working because
we're building against a specific Wildfly / EAP version and build the
modules taking advantage of our knowledge of the specific versions
we'll encounter in there, but it's getting more complex quickly.

I understand that some people will be happy enough to state they
depend on "ORM 4.3" rather than "ORM 4.2" and having you drop-in micro
updates as convenient. In *theory* we promise full drop-in backwards
compatibility on the micro version so we should be able to expect a
user to just need to specify the major.minor, but there's the
possibility of unintentionally breaking this promise (a bug) or - as
historical facts - either OGM or Search needing a specific version.

Sometimes it's just more practical for us to break our "internal
contracts" even in a micro release, to move on timely; in this case we
require a specific micro of ORM even though the exposed contract to
end users and other integrators is still backwards compatible.

So I think it would be better to have both module representations
(major.minor and major.minor.micro): we'd consider the .micro
variation as something people shouldn't use unless they have a
specific need.. but it's good to be able to use it when such a
specific need arises.
Still if that's too inconvenient, just having the major.minor would be
an improvement on current state :)

No other project raised such needs on the WildFly mailing list?
(except Infinispan, which is in our same needs)

Sanne