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" <gun...@hibernate.org> > To: hibernate-dev@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@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
