Re: [hibernate-dev] 5.3?
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 <smarlow(a)redhat.com
<mailto:smarlow@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/s...
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>