[hibernate-dev] Changing method signatures in micro releases

[Gunnar Morling]

Gail, Steve,

Thanks for your replies.

2014-05-20 15:28 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

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

That's good news.

In your other mail you said "We simply have not yet done the packaging
split there"; Is this to say AbstractCollectionPersister will move into
another package in the future which makes more apparent that it is an SPI
type?


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

I mean doProcessQueuedOps() whose signature has changed between 4.3.4 and
4.3.5 from

    protected abstract void doProcessQueuedOps(PersistentCollection
collection, Serializable key, SessionImplementor session)

to

    protected abstract void doProcessQueuedOps(PersistentCollection
collection, Serializable key, int nextIndex, SessionImplementor session)

Our implementation used to override the former and thus didn't compile
against 4.3.5 after doing the update. I'm now declaring both versions, so
we can run with ORM <= 4.3.4 and >= 4.3.5.

--Gunnar



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