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