What changes are we talking here specifically? Have they been done
intentionally or by accident?
For the better or worse, ORM - so far - doesn't stick to SemVer rules, so I
don't think we should revert anything which has been changed on purpose.
Different story for accidental changes of course.
In HSEARCH we are using a tool named "japicmp" (
http://siom79.github.io/japicmp/) for creating a report with changed public
API/SPIs. Running this prior to a release - comparing to the last stable
version - helps to detect any unintentional changes and create a public
report / migration notes for intentionally changed things.
2016-06-20 12:47 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
On 20 June 2016 at 08:33, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
> Are the incompatibilities here for good on ORM, or could they be
> reverted / softened in the 5.2 branch to allow for an easier path?
I'm working on a set of PRs for both ORM and Search which reduce the
list of incompatibilities,
but while the amount of issues is getting lower I strongly suspect
that I won't be able to get it down to zero.
Of course some more changes on ORM SPIs could be reverted but I don't
feel like that's something we could do in a micro..
-- Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev