Scott, I think the most reliable way is to have you setup a WildFly
job which tests snapshots of Hibernate and Infinispan of the branches
you intend to merge next in WildFly. AFAIK it would also save you some
time, as you seem to constantly run such builds?
I think that we talked about doing that a few years ago. I setup a CI
job that built Hibernate master, Infinispan master and tried to build
WildFly with the two but it didn't work. One of the problems was that
WildFly wouldn't build without code/configuration changes to adjust for
the Infinispan (master) changes that had been made since the version of
Infinispan that was integrated.
https://github.com/wildfly/wildfly/pull/7896 is the pull request for
upgrading WildFly 10 to use Infinispan 8. I'm not sure how much of it
is optional but I'm guessing a lot of the changes are needed for WildFly
to work at all with Infinispan 8.
In order for this testing to work, Infinispan would need to maintain
compatibility (e.g. configuration/api/spi) for at least one major
version back. I'm not sure if there are any other problems to overcome
before doing WildFly/Hibernate/Infinispan testing.
I suppose that another problem, when we integrate the latest WildFly
master the latest master branches for Infinispan/Hibernate, we will
likely see failures as new features are being developed (not everything
works on day one of a new major release cycle). Its probably closer to
the end of a development cycle (when all three development teams are
ready to be spammed that they have integration bugs that need to be
fixed). But, if we all agree that we need to keep integration working
from the start of a new major release cycle, this could work. We also
need to sign off on keeping compatibility as mentioned above.
Does Infinispan want 8.0 to be fully (configuration/API/SPI) compatible
with 7.x? How about 9.0 with 8.0?
Scott