3:28 a.m.
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
3:34 p.m.
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
6:16 p.m.
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
9:18 a.m.
Persisters are most certainly not generally considered APIs. We simply
have not yet done the packaging split there. APIs are things you use in
your application. Applications generally are not calling persisters in
normal usage.
On Mon, May 19, 2014 at 2:34 PM, Gail Badner <gbadner(a)redhat.com> wrote:
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
9:28 a.m.
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.
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.
On Mon, May 19, 2014 at 2:28 AM, Gunnar Morling <gunnar(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:59 a.m.
Gail, Steve,
Thanks for your replies.
2014-05-20 15:28 GMT+02:00 Steve Ebersole <steve(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
6:08 p.m.
My changes for HHH-9204 and HHH-9205 need to be pushed to 4.2, 4.3, and master. This needs
to happen by early next week so it can be released in 4.2.13.Final on Wednesday.
I want to make sure that my change fixes the regression introduced into 4.3.5 and 4.2.12,
without breaking the fix that Gunnar made for OGM.
Gunnar, can you check my pull request at
https://github.com/hibernate/hibernate-orm/pull/747 and make sure it doesn't break
something for you?
Thanks!
Gail
----- Original Message -----
From: "Gail Badner" <gbadner(a)redhat.com>
To: "Steve Ebersole" <steve(a)hibernate.org>
Cc: hibernate-dev(a)lists.jboss.org
Sent: Monday, May 19, 2014 3:16:56 PM
Subject: Re: [hibernate-dev] Changing method signatures in micro releases
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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:07 a.m.
2014-05-24 0:08 GMT+02:00 Gail Badner <gbadner(a)redhat.com>:
My changes for HHH-9204 and HHH-9205 need to be pushed to 4.2, 4.3,
and
master. This needs to happen by early next week so it can be released in
4.2.13.Final on Wednesday.
I want to make sure that my change fixes the regression introduced into
4.3.5 and 4.2.12, without breaking the fix that Gunnar made for OGM.
Gunnar, can you check my pull request at
https://github.com/hibernate/hibernate-orm/pull/747 and make sure it
doesn't break something for you?
Yes, that works from OGM's perspective.
I'm only wondering about the deprecation; Are you intentionally deprecating
the new variant of the method (with the additional "nextIndex" param)? This
had been established as part of the original bug fix, so I'd have expected
that the old variant of the method (without that parameter) would be
deprecated instead. Or is the original fix not required anymore?
Thanks for your help,
--Gunnar
Thanks!
Gail
----- Original Message -----
> From: "Gail Badner" <gbadner(a)redhat.com>
> To: "Steve Ebersole" <steve(a)hibernate.org>
> Cc: hibernate-dev(a)lists.jboss.org
> Sent: Monday, May 19, 2014 3:16:56 PM
> Subject: Re: [hibernate-dev] Changing method signatures in micro releases
>
> 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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
2:04 p.m.
The original bug could have been fixed without changing the SPI, since it only affected
OneToManyPersister. Since there was no reason to change the SPI in the first place, I
opted to deprecate the new method and keep the old.
Thanks for checking it!
Gail
----- Original Message -----
From: "Gunnar Morling" <gunnar(a)hibernate.org>
To: "Gail Badner" <gbadner(a)redhat.com>
Cc: "Gunnar Morling" <gunnar(a)hibernate.org>,
hibernate-dev(a)lists.jboss.org, "Steve Ebersole" <steve(a)hibernate.org>
Sent: Monday, May 26, 2014 1:07:10 AM
Subject: Re: [hibernate-dev] Changing method signatures in micro releases
2014-05-24 0:08 GMT+02:00 Gail Badner <gbadner(a)redhat.com>:
> My changes for HHH-9204 and HHH-9205 need to be pushed to 4.2, 4.3, and
> master. This needs to happen by early next week so it can be released in
> 4.2.13.Final on Wednesday.
>
> I want to make sure that my change fixes the regression introduced into
> 4.3.5 and 4.2.12, without breaking the fix that Gunnar made for OGM.
>
> Gunnar, can you check my pull request at
> https://github.com/hibernate/hibernate-orm/pull/747 and make sure it
> doesn't break something for you?
>
Yes, that works from OGM's perspective.
I'm only wondering about the deprecation; Are you intentionally deprecating
the new variant of the method (with the additional "nextIndex" param)? This
had been established as part of the original bug fix, so I'd have expected
that the old variant of the method (without that parameter) would be
deprecated instead. Or is the original fix not required anymore?
Thanks for your help,
--Gunnar
> Thanks!
> Gail
>
> ----- Original Message -----
> > From: "Gail Badner" <gbadner(a)redhat.com>
> > To: "Steve Ebersole" <steve(a)hibernate.org>
> > Cc: hibernate-dev(a)lists.jboss.org
> > Sent: Monday, May 19, 2014 3:16:56 PM
> > Subject: Re: [hibernate-dev] Changing method signatures in micro releases
> >
> > 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
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
3620
days inactive
3628
days old
8 comments
3 participants
participants (3)
-
Gail Badner -
Gunnar Morling -
Steve Ebersole