On 08/18/2016 03:52 PM, Steve Ebersole wrote: > I'm not following the 5.2 -> 6.0 piece. You mean because we merged the > JPA contracts into our version of those contracts directly?
Yes, as part of that change, I believe that we also made some changes to which exceptions are being thrown, which could require existing Hibernate applications to change code when migrating to 5.2+. I'm not against the merging of the JPA contracts, just am (late) questioning if that could be moved to a later ORM release. > That led to > very few *real* migration problems. The only ones I know of are the > once where we had to rename the Hibernate version of a method because > JPA happened to use the same name mainly around enums. > > And also we do not have the resources to simultaneously develop new > features on multiple branches. We've been there before[1]. So whether > you want to name 5.2 6.0 or whatever, the point is the same.. from that > point on that is where we focus new feature dev on top of... not > backwards... not to multiple places... Mostly, I'm trying to understand when we might be able to see some of the ORM 5.2+ branches show up in a future WildFly release. It would be great to see the SQM + other coming goodies, show up in WildFly sooner rather than later, but WildFly needs to avoid breaking (application) compatibility with earlier releases. Perhaps we should look at whether breaking compatibility in certain APIs, could be allowed in WildFly. Such, that WildFly application that use the Hibernate ORM native api, could expect to make code changes when upgrading to a new WildFly release, that contains a new Hibernate release. > > > [1] https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team > > > On Thu, Aug 18, 2016 at 7:42 AM Scott Marlow <smar...@redhat.com > <mailto:smar...@redhat.com>> wrote: > > > On 08/17/2016 03:54 PM, Steve Ebersole wrote: > > For whatever reason discussion about JavaMoney/Moneta support has > heated up > > again the past few days. Is this important enough to warrant a > 5.3 release? > > My (late) vote is to rename 5.2 -> 6.0 and have the 5.3 release be based > on the current ORM 5.1 branch. 5.3 would include changes that are > compatible with ORM 5.0.x applications (so that 5.0 users can migrate to > 5.3, without having to rewrite code). 5.2 users would then migrate to > 6.0, which would continue to have the same changes (plus whatever else > is included). I'm thinking that this would open up a path for new ORM > features to be made available to ORM 5.0.x applications, via the 5.3+ > releases. > > > > > If we are going to cut a 5.3 I'd also suggest we include the > recent work I > > did in regards to CDI support as well[1]. > > > > > > [1] > > > > https://github.com/sebersole/hibernate-core/tree/wip/6.0/hibernate-core/src/main/java/org/hibernate/resource/cdi > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org <mailto: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
