On 20 June 2016 at 08:33, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: I'm working on a set of PRs for both ORM and Search which reduce the list of incompatibilities, but while the amount of issues is getting lower I strongly suspect that I won't be able to get it down to zero. Of course some more changes on ORM SPIs could be reverted but I don't feel like that's something we could do in a micro.. -- Sanne

On 20 June 2016 at 12:03, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: The change with highest impact on Search is that the various Query API interfaces have been moved. The legacy contracts still exist in the original location, but are deprecated and extend the new types; this might be all good for end users - and necessary as some JPA and "native" APIs have been merged -, but we actually extend these interfaces with the Fulltext versions, and have custom implementations of each.. which implies we now have to implement also the new methods of the new contracts. It might be possible to introduce a base class in ORM for Search to extend - like we did in the past for other components - but even doing so this same base class should also be backported to older ORM versions which we want to support with the same Search build; this means we could support newer bugfix releases of the older minor branches, but the trick won't work with e.g. existing Wildfly unless we get them to do a release with such a newly patched ORM. BTW it's all non-trivial as other elements which need to be passed the Query implementations - like Metadata related types - have also been moved. Then there are several smaller issues which could be easily solved, but add up in complexity: eg some services have been moved in a different SPI package, and Search used to lookup these services by class type. We'd need to re-introduce the old service type as a deprecated interface within the ORM sources, and patch ORM's serviceregistry so that when asking X you actually get the newer version Y of that same service (downcasted). These minor things are doable but are a pointless exercise if the bigger impact issues (the Query API) don't get addressed as well. The doubt is that this is all not worth it: ideally I'd prefer to have Hibernate Search stick on ORM 5.1 for a while longer, and upgrade to ORM 5.2 when a WildFly 10.x release introduces ORM 5.2, or if we could have those ORM 5.2 modules for any WildFly version. At that point we'll require ORM 5.2, let's aim at not have people wait too long for that - at least we'd be spending energy in forward-moving progress rather than on maintenance which will be useless soon enough. Thanks, Sanne