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 <sa...@hibernate.org>: > On 20 June 2016 at 08:33, Emmanuel Bernard <emman...@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@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
