Reconsider the release approach

Currently the new release pipeline releases both Persistence API and Persistence TCK artifacts at the same time. This works fine for Persistence API releases. We may have a problem if we what to create a release of TCK only, e.g. we accepted some TCK challenges and want to have a patched version of TCK published. This will result in the API being published as well...

I was wondering if it would be fine to add a flag to the release pipeline to publish only the TCK. If so how do we version it (version is tied to the project version which defines the API version as well). Do we go with 4.0.0.SP1 for the patched TCK release for 4.0.0 version of API?

Just bumping the patch version without the release of API will result in potential version jump in the API releases ...

(this question came up while I was thinking about the maintenance release of 3.2 TCK we were hoping to get out...)

The issue does not name specific files or tests; start by tracing the current release pipeline and how the shared project version is defined for Persistence API and TCK artifacts. Determine whether TCK-only publishing and independent versioning are supported, then document a decided release and versioning approach that avoids publishing the API unnecessarily.