I wouldn't go as far and call it "very wrong"; There just hasn't been any demand for running several OGM versions in parallel, so no one cared for enabling such scenarios. That said, 5.0 seems like a good time to do so as I can see some people might want to use 4.2 and 5 in parallel, so +1 for doing it. to be released with a different slot id I don't think the purpose of these props has been so much releasing with different ids, but more maintaining the slot ids in one place (e.g. "hibernate.ogm.mongodb.module.slot" is referenced twice, once in module.xml and once in dist.xml). If you see room for simplifications, go for it; But I wouldn't spend huge amounts of time on it, given this is working. 2016-03-29 13:19 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > I just noticed something which seems very wrong with the OGM modules, > although I guess I'm correcting a mistake of a younger self :) > > The various modules of Hibernate OGM use the "main" slot, rather than > using the version of the project. > This makes it impossible for people to deploy different versions of > OGM, or worse it makes it possible for people to unintentionally > overwrite some parts of it with a different version. > > In Hibernate Search we learned long ago - probably thanks to the > experience of the complex integration with both WildFly and Infinispan > and others - that it's much safer to provide modules using the slot > name "major.minor", i.e. we'd have "5.0" for the upcoming OGM release > 5.0.0.Final. > > Even better, we should publish the public modules (the ones the end > users are expected to mention in their configuration files / metadata) > with this scheme, but these to be aliases which resolve to the > specific version: that allows people to be decoupled from the micro > updates, yet be able to override this in case of need and still > require a specific micro. > > to be released with a different slot id (i.e. couchdb and mongodb > modules could use a different scheme) and I currently can't think of > when this is useful, I'd suggest we get rid of that and make it all a > bit simpler. > > Since I'm cleaning up other modules changes now I'd like to do this right > now? > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >