We do strive to maintain backwards compatibility of SPIs. That being said, there are times when fixing a bug requires a new SPI method. Which *seems* to have been the case here.
First, I am not sure what you mean by OGM "naturally still override the old signature". What "old signature"? This is a completely new method. The change here introduced CollectionPersister#processQueuedOps. AbstractCollectionPersister implements that processQueuedOps somewhat eventually delegating to doProcessQueuedOps. Do you mean processQueuedOps? If so, both these methods were added at the same time. On Mon, May 19, 2014 at 2:28 AM, Gunnar Morling <gun...@hibernate.org>wrote: > Hi, > > When updating Hibernate OGM to make use of ORM 4.3.5, I noticed a changed > method signature in AbstractCollectionPersister (abstract > method doProcessQueuedOps() has a new parameter). > > This causes a compilation failure in OGM, as we naturally still override > the old signature. I can solve this particular case in a compatible manner > by declaring both variants of the method in our sub-class (omitting the > @Override annotation), but I'm wondering how we should generally deal with > this kind of issue. > > Are micro-releases considered strictly backwards-compatible, so that e.g. > all of ORM 4.3.x should be useable together with an integrator (such as > OGM) known to work with 4.3.0? This would have been my assumption > originally. > > Are there any rules for what kind of changes are to be expected by an ORM > micro/minor/major update? > > Thanks, > > --Gunnar > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
