[hibernate-dev] Changing method signatures in micro releases

[Gail Badner]

Hi Gunnar, 

Thanks for mentioning this. I believe that org.hibernate.persister.collection and org.hibernate.persister.entity are considered APIs, which should definitely be backward-compatible for micro releases.

I'm looking at some alternatives to mitigate that. My first thought is that the fix for HHH-9078 should have been made only to OneToManyPersister, so that AbstractCollectionPersister would not be affected. If this is possible, I will add the old method back and deprecate the new one that caused you trouble.

I'll let you know what I find.

Regards,
Gail

----- Original Message -----
> From: "Gunnar Morling" <gunnar at hibernate.org>
> To: hibernate-dev at lists.jboss.org
> Sent: Monday, May 19, 2014 12:28:38 AM
> Subject: [hibernate-dev] Changing method signatures in micro releases
> 
> 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
>