smarlow at redhat.com
Fri Aug 19 10:20:53 EDT 2016
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. 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.
>  https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team
> On Thu, Aug 18, 2016 at 7:42 AM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at 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+
> > 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.
> > 
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
More information about the hibernate-dev