Hi David, Regarding (1):
I agree that the current naming might lead to confusion or misaligned user expectations if we just include JPA 3.2 :) If we go with a version-based approach, something like 10.1-jpa32 could work well—it would clearly indicate the specific change we're making to the EE10 uberjar. T he only consideration is whether we want to do a release with just the EL API fix [1] before introducing any JPA 3.2-related changes to the API jar. Regarding (2): My initial thought was to release TomEE 10.1.1 with the EL API fix and the dependency updates we've made so far (Tomcat, etc.). Following that, we could move to version 10.2, which would include the JPA 3.2 EE API shade artifact to clearly signal the change. The only downside is that this would require multiple release votes, which could be time-consuming for our volunteer contributors. As for OpenJPA, development toward JPA 3.2 is currently happening on a separate branch and hasn’t been released yet. Once it becomes available, upgrading should be straightforward. Gruß Richard [1] https://github.com/apache/tomee-jakartaee-api/commit/7c5db38d04e212a9acafcde1dd20e7f55236df66 > Am 28.07.2025 um 20:15 schrieb David Blevins <david.blev...@gmail.com>: > >> On Jul 20, 2025, at 11:04 AM, Richard Zowalla <r...@apache.org> wrote: >> >> Hi, >> >> Just a quick update: >> >> I created an API snapshot using JPA 3.2 and deployed it to repository.a.o. >> Then, I updated the version on the jpa3.2 test branch and ran a full build, >> including the TCKs where set up: >> https://ci-builds.apache.org/job/Tomee/job/pull-request-manual/163/ >> I also added a few tests to verify compatibility with EclipseLink, OpenJPA, >> and Hibernate 6. >> >> Everything looks good so far. How shall we proceed? >> >> Maybe something like: >> >> (1) Release EE API with the fix for EL by Markus > > Saw this thread come in and have been thinking and can't seem to find and > good approaches. The concern is having something called Jakarta EE 10 API > that has Jakarta EE 11 APIs in them. Ideally we call that out in some way a > user could notice. > > I can't think of any good solutions other than to add some word to the > version such as "modified" or "upgraded" or similar. Some kind of hint that > could tip off a user. > >> >> (2) Do a TomEE 10.1.x release with the fixes / dev upgrades we have so far > > We created a 10.1 because we changed the MicroProfile API level. I think > that was a good call and we likely want to stay consistent with that practice > and do a 10.2 to reflect the changed version, skipping 10.1. Are we > upgrading our OpenJPA major version as well? > >> (3) Release EE API with JPA 3.2 + TomEE 10.2.x release soon after? > > This sounds like a good approach. > > > -David
