Re: [hibernate-dev] Hibernate ORM modules published as major.minor and an alias for main
On 15 January 2015 at 16:01, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
On 15 Jan 2015, at 16:54, Scott Marlow <smarlow(a)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