Wave discussion: design and approve mechanism for recording behavioral (aka non-binary) intra-spec dependencies

[edburns]

In spec documents defined dependencies to other component specs are hard to maintain, as this need to be done manually.

We need a machine readable version to be able to automate maintenance of the dependencies and derive component specs wave allocation from it!

Goal should be to define a dependency only once for a spec.
This could achieved by defining the dependency in the spec documents Maven POM with a version property and use an AsciiDoctor Attribute to display the version in the document from the POM.
Current limitation: The full version (without omitting something like a Patch/Service Release part) will be displayed. A makro might solve this, but from my point of view it is super important to not drop information about versions with issues like CVEs.
Semantic Versioning rules in conjunction with "provided" could be used to declare that higher versions allowed instead (higher Patch and Minor Releases - for Major Releases there is no guarantee at all).

With such defined dependencies in spec documents, tools like jQA could analyse and verify them.

This approach can be extended by using a Maven multi-module setup in the git repository (like in MicroProfile or Jakarta Concurrent):
A component spec parent can define version properties and submodules like the spec (document), API and TCK derive this version - changes can be done on one single place!
As these parts of a spec are coupled strongly, this automation could help a lot maintaining deviating dependency version issues we face currently...
As a side effect, there will be only one issue tracker on that mono repo left (instead of up to three) and Continous Integration could be established to check the quality of a contribution in the future (like does that new feature contain a test and a reference to the spec document?).