Hello all, we generally have been trying to target the versions of Infinispan provided by the WildFly version we're targeting for compatibility with a specific OGM release cycle.
I would like to change that, and for example now switch to the latest Infinispan 8.1.0.Final (rather than the one in WildFly 10 candidate release, which would be 8.0.2.Final). Several reasons: # shall not use the WildFly Infinispan distribution in WildFly the specific Infinispan version being integrated is an implementation detail. People wanting to use Infinispan directly, or for other means than the ones addressed by the WildFly clustering features which are based on Infinispan (but don't expose it), should be encouraged to download the Infinispan modules from the Infinispan project. We should apply (and encourage) this practice too. # pick our own version it's obviously nicer for us to reserve ourselves the practical benefits of being able to pick our own version according to needs, rather than stick with wathever WildFly requires. # we might have a need for latest Infinispan probably no need to explain ;) I don't with us to wait for an app-server update cycle when we need an upstream patch. # don't aim at a single WildFly version while we're currently running integration tests with latest WildFly, I think it's desirable to use that as a testing bed for the modules we provide but not as a coupling factor for our dependency matrix. In other words, let's prepare OGM to be able to produce modules for different versions of the application servers (and not least other application servers although that's unrelated). Not least, the fact that the app server is sticking with some version shouldn't have an impact to all of our users who have no interest in this particular appserver at all. Am I missing any important counter argument? Thanks, Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
