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

On 16 Jan 2015, at 13:58, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: On 15 January 2015 at 16:01, Emmanuel Bernard <emmanuel(a)hibernate.org <mailto:emmanuel@hibernate.org>> wrote: > > On 15 Jan 2015, at 16:54, Scott Marlow <smarlow(a)redhat.com&gt; 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)