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 <gunnar(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev