Re: [jakartaee-tck-dev] TCK Versioning question about EE TCKs that move

[James Perkins <jperkins@xxxxxxx>]

This is my personal opinion, but any TCK's moved out of the platform should use a different groupId. If they don't, then they MUST use the EE versioning, e.g. 11, 12, 13, etc. Otherwise at some point you end up with a conflict. Plus the versioning would look weird in that jakarta.tck:ejb32:4.1.0 would be newer than jakarta.tck:ejb32:11.0.2.

What they did in this project, e.g. use jakarta.ejb.tck and the 4.x versioning, is correct and what we should encourage other projects to do. 

James R. Perkins

Software Developer 

IBM

---

From: jakartaee-tck-dev <jakartaee-tck-dev-bounces@xxxxxxxxxxx> on behalf of Kyle Aure via jakartaee-tck-dev <jakartaee-tck-dev@xxxxxxxxxxx>
Sent: Thursday, April 23, 2026 09:28
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Cc: Kyle Aure <kylejaure@xxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] TCK Versioning question about EE TCKs that move to spec projects...

 

For Jakarta Data and Jakarta Concurrency we use a consistant version number for the API and TCK even if a change only went into one, and the SPEC version is only major. minor. I know there was some friction about us doing that, but both communities

For Jakarta Data and Jakarta Concurrency we use a consistant version number for the API and TCK even if a change only went into one, and the SPEC version is only major.minor. 

I know there was some friction about us doing that, but both communities voted to keep it that way because it simplifies the release process and it's easier for consumers to just use the same version everywhere without having to worry about diverging version branches for the API vs TCK. 

If I understand your situation, I would think that if the spec is removing security manager and it requries an update to the SPEC then you would have to do a minor release and thus your API and TCK version would be 4.1.0 and your SPEC version would be 4.1.

For EE 13 if all you do is a service release your API and TCK would move up to 4.1.1, but the SPEC would stay at 4.1 because if you were to make a change to the SPEC you would HAVE to do a minor release instead.  

That is how I would do it :shrug:

Thanks, Kyle

On Thu, Apr 23, 2026 at 10:55 AM Scott Marlow via jakartaee-tck-dev <jakartaee-tck-dev@xxxxxxxxxxx> wrote:

While I'm asking this question specifically about the Enterprise Beans TCK tests that were moved to the Enterprise Beans spec project, I'm curious about the same for other projects as well.

The tests under https://github.com/jakartaee/platform-tck/tree/11.0.x/tcks/apis/enterprise-beans were moved to https://github.com/jakartaee/enterprise-beans/tree/master/tck and removed from the Platform TCK main branch.

My versioning question is what artifact version should the Enterprise Beans TCK tests be released under for the next few EE releases?  There will be a minor release of Enterprise Beans 4.1 that removes the security manager so we the Enterprise Beans project might release the TCK under (based on spec version) 4.1.x or perhaps 12.x (based on EE version) but what about EE 13?

It is kind of nice for the TCK version to match the Enterprise Beans spec version but what about adding EE 13 tests in which case the TCK version couldn't be 4.1.x if we add new tests.

Perhaps the TCK version for Enterprise Beans could be independent of the Enterprise Beans spec version.  Regardless, no perfect answer.

Thoughts?

Thanks,

Scott

_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev