[infinispan-dev] Hibernate ORM 5.0.0.CR4 not working so well with Infinispan 8.0.0.Beta2...

[Sanne Grinovero]

Hi Scott,


On 6 August 2015 at 13:33, Scott Marlow <smarlow at redhat.com> wrote:
>>
>> 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.

I agree, that would be horrible. The two are different independent
projects, and hoping that the two masters work flawlessly with each
other every day would be a foolish assumption: that's *not* what I
suggested.

What I suggested is that you have a job running which monitors the two
branches which you're planning to get working together, and ideally
within WildFly too. In this specific case, they happen to be {master}
and {master} of each project, but that's a coincidence as that's the
current aim: we intentionally want these two versions to work together
in the same platform.

And things seemed to work a week ago... what was really disappointing
today, was to figure out that there was a regression *after* we tagged
the ORM release.
When we reach such a point in which it looks like they are converging
fine, that's when we need to setup such a WildFly CI job: if only we
had known yesterday before the release, you'd be merging them both in
WildFly today. Or someone could have run a manual test, but this could
be done by a bot.

> 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.

Both projects need to be able to freely evolve between major versions.
But occasionally, someone from the WildFly team is going to start
planning and pick versions from these projects - not necessarily the
latest - at that point you start testing and see if the choice is
valid, request integration fixes, and should also reconfigure the
"convergence jobs".

It sounds like you spend a lot of time testing such integrations, so
we should automate those builds and make sure we get preventive
reports: saves a lot of critical time.

> 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?

No those are obviously non viable options; for example I think the
specific change in Infinispan which caused all this trouble is
perfectly fine: there are lots of things which can be done, the
problem is just that we're notified of these problems very late in the
game.
Both projects need to experiment and evolve without expensive
constraints, we only need specifically selected branches to work
together.

Thanks,
Sanne

>
> Scott
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev