I didn't mean to suggest that we fully implement both JPA 3.x and JPA 2.y in any one version.
I'm really just focusing on those principles I mentioned; the main ones being: - don't spend ages on this effort - don't add pressure on ORM 6 - not getting in the way of eventual ORM6 adoption What happens next is definitely very open up for options, but bear in mind that we might need to have some JPA3 implementation soon, so some plan needs to be devised. As a broad idea, WildFly would like to have it by September - that's not fully decided and they are asking us how reasonable that could be. In more formal terms, we have the spectrum of certifications: - [fact] Hibernate ORM 5.3 passes the JPA 2.2 TCK (as does ORM 5.4) - [goal] to have Hibernate ORM 6 (or 7?) to pass the JPA 3.0 TCK & certification To be fair what happens in the middle is more like a gray area. I agree with Steve on wondering about how far we want stuff to be simultaneously supported: in my opinion it would be totally fine if - for example - Hibernate ORM 5.5 would materialize as a special edition which is totally backwards compatible, able to pass the JPA 2.2 TCK, and perhaps also able to load entities mapped via JPA 3 annotations while not exposing anything else from Jakarta. As long as we don't aim at JPA certification we can of course do whatever works for us, so let's take this as an option. A second step would be - assuming ORM6 branch incorporates such changes - to also support both JPA 2.2 and JPA 3.0 annotations in the ORM6 branch, but completely switch to the JPA 3.0 API and configuration settings so to keep things simple. The "big bang" approach that Validator implemented is an option as well; but the context is a bit different as we're having an actual major release being developed, and the matter of possible time pressure. We know from experience that people tend to linger on the older versions for too long, so you need both a carrot and a stick to move on. It would be good to be able to say to people that want JPA3 that they need to upgrade to 6; and yet it also needs to be relatively easy to upgrade - and that's where we have a problem: Jakarta haves you "just search and replace all javax. strings" - but if we incidentally also ask people to adapt to all changes from ORM5 to 6 - even if they are small - it muddies the strategy significantly. Conceptually I'm not sure if JPA3 is going to scare people off or rather make people interested, as some might want to avoid it as there is no immediate benefit, while others will need it: surely we'll have many users in both camps. Yet I'm convinced that having a release which provides full JPA 3.0 TCK between 5 and 6 (or however it gets renamed) would be no good to us, as it would create an adoption barrier for both cathegories of people: the ones not interested to migrate away from JPA2, and the ones not interested to migrate beyond JPA3. Finally, consider the timeline. Both WildFly and Quarkus will need a JPA 3 implementation soon: we either have it all ready or we need to be able to deliver at least support for the mapping so that they can do some bytecode magic to cover the other areas such as API; that's why I see some merits in having some flexible intermediate support - POC pending of course. Thanks, Sanne On Tue, 10 Mar 2020 at 14:39, Steve Ebersole <st...@hibernate.org> wrote: > > I'm curious... why are we saying that we need to simultaneously support > both sets of annotations and config settings? > > As a user, if I choose to use the Jakarta-based JPA I would fully expect > that to only work with the Jakarta-based annotations and settings. > > Is there something in the spec I am missing that says we need to understand > both simultaneously? > > On Tue, Mar 10, 2020 at 9:21 AM Guillaume Smet <guillaume.s...@gmail.com> > wrote: > > > Hi, > > > > On Tue, Mar 10, 2020 at 2:48 PM Yoann Rodiere <yo...@hibernate.org> wrote: > > > > > > In particular I wonder, how would you all feel if (for example) > > > > Hibernate ORM 5.5.x were to depend on both JPA 2 and JPA 3 API > > > > artifacts? > > > > > > Mixed feelings, to be honest > > > > > > Same here. I thought we decided against supporting both at the same time. > > > > As for HV, I won't. HV 7 will only support jakarta packages all over the > > place. And if you want jakarta packages, you will have to use HV 7. And > > it's going to be a big bang, meaning you also need jakarta-package CDI and > > so on. > > > > That is an important point for ORM too because that means you will have to > > also support both legacy CDI and new jakarta CDI if you want to support > > both at the same time. Pretty sure it's going to be a nightmare. > > > > Quick feedback on the HV move: it was relatively easy (but it's less > > code/complex than ORM). > > > > >From my point of view, the options are: > > 1/ > > - release an ORM 5.5 with Jakarta packages but it will break all existing > > applications in a minor, not ideal > > - move 6 to jakarta packages too to avoid conflicts > > > > 2/ > > - rename 6 to 7 (or 8) > > - release a 6 (or 7) with jakarta packages > > > > I don't think tying the Jakarta package release to the 6 cycle is a good > > idea so that's not an option for me. > > > > Note that in any case, some patches will be significantly harder to > > backport to 5.4 (and vice versa). > > > > -- > > Guillaume > > _______________________________________________ > > 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev