The used version is also outdated, as in MP 6.0 it is planed to use 3.0.1 (instead of 3.0), that is not released yet. So this use of combining component spec service releases in the platform release without following the dependency tree and defining a minimum version (aka using a range in fact) can create issues.
Regarding the property use, this could be fixed by using it in the TCK (then it may be renamed too, for better recognition) or it could be deleted simply (other TCK dependencies have no parent POM version property too, like Jakarta Validation).
The referenced version should be in sync with the version that will be defined in the MP release, so 3.0.1 here and that means, releasing the MP (Platform) requires to release it's compontents from the bottom to the top of the dependency tree to keep them in sync.
As this affects the TCK here only, there is a risk of testing with or against an old version, that could create an issue late in the MP release process, when the MP implementation tests combined specs with other (newer) versions (or even worse: testing against the same old versions, but delivering newer ones).
In short: The (test) environment for the component spec should be the same as the platform environment.
There is a defined property for the MP REST Client version here:
https://github.com/eclipse/microprofile-open-api/blob/8c8adaad12a7dd4cdd0bd12bb3967e60d62db98f/pom.xml#L39
But it is not in use here in the TCK: https://github.com/eclipse/microprofile-open-api/blob/8c8adaad12a7dd4cdd0bd12bb3967e60d62db98f/tck/pom.xml#L53-L58
The used version is also outdated, as in MP 6.0 it is planed to use 3.0.1 (instead of 3.0), that is not released yet. So this use of combining component spec service releases in the platform release without following the dependency tree and defining a minimum version (aka using a range in fact) can create issues.
Regarding the property use, this could be fixed by using it in the TCK (then it may be renamed too, for better recognition) or it could be deleted simply (other TCK dependencies have no parent POM version property too, like Jakarta Validation).
The referenced version should be in sync with the version that will be defined in the MP release, so 3.0.1 here and that means, releasing the MP (Platform) requires to release it's compontents from the bottom to the top of the dependency tree to keep them in sync. As this affects the TCK here only, there is a risk of testing with or against an old version, that could create an issue late in the MP release process, when the MP implementation tests combined specs with other (newer) versions (or even worse: testing against the same old versions, but delivering newer ones). In short: The (test) environment for the component spec should be the same as the platform environment.