[hibernate-dev] Changing method signatures in micro releases

[Steve Ebersole]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>