It was a simple matter to restore the old the method and provide a default implementation
of the method added by HHH-9078.
I've create the following issues:
For master, 4.3, and 4.2 (because HHH-9078 was fixed on master, 4.3, and 4.2):
HHH-9204: Restore AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
Serializable, SessionImplementor)
HHH-9205: Deprecate AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
Serializable, int, SessionImplementor)
For master only:
HHH-9206: Remove AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
Serializable, int, SessionImplementor)
Steve, I'm not 100% I did the right thing for HHH-9204 and HHH-9205, so please take a
look at the pull request:
https://github.com/hibernate/hibernate-orm/pull/747
Thanks,
Gail
----- Original Message -----
From: "Gail Badner" <gbadner(a)redhat.com>
To: "Gunnar Morling" <gunnar(a)hibernate.org>
Cc: hibernate-dev(a)lists.jboss.org
Sent: Monday, May 19, 2014 12:34:09 PM
Subject: Re: [hibernate-dev] Changing method signatures in micro releases
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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev