[jakartaee-platform-dev] Discussion of how dependencies trigger updates

[Scott Stark <starksm64@xxxxxxxxx>]

Today's discussion was centered on what impact both minor and major and potentially breaking updates to individual specs and their APIs have on specifications that depend on the changes at either the spec level or both the spec and API level.

CDI 4.0 is a major update that has breaking changes both due to removal of deprecated APIs, possibly changes to some APIs, and certainly the default semantics of interpreting how to identify the CDI beans in a bean archive.

Three specs that have a dependency on CDI but have no current plans for anything other than service release updates are Bean Validation(BV), Transactions(JTA), and Batch.

BV has no dependency on the CDI APIs. It mentions requirements that containers and dependency injection frameworks should follow in order to make BV ValidatorFactory, Validator(s), ConstraintValidator(s), etc. be made available to the application components. So if an implementation of BV relies on CDI to achieve this, it will potentially have to be updated to work with a CDI 4.0 environment.

A BV 3.0 -> 4.0 update to the specification and API artifact does not make sense to me for this dependency as nowhere would there be a change to accomplish this. Again, there are no API dependencies, and the references to dependency injection are abstract and make no mention of APIs or artifact semantics. All of those details are covered in the CDI spec itself that BV is bundled with by virtue of the Platform spec.

JTA does have a dependency on the CDI Nonbinding and NormalScope annotations, and it's API artifact has a dependency on CDI 3.0.0-M1 with a provided scope. Neither of these annotations has changed in terms of either compile time or runtime semantics. 

Here again I don't see that a JTA 2.0 -> 3.0 update is warranted for simply due to the dependency. We are doing a service release to add a module-info, so it also makes sense to update the dependency on CDI to be consistent with the platform, but if there was no other reason for a service release, why do one just to update the dependency?

Batch is similar to JTA in that is has a dependency on the CDI Nonbinding annotation, and a provided scope dependency on the 3.0.0 CDI API artifact. The Batch spec does state that @Inject from CDI must work with @BatchProperty when used. It does not go into what CDI deployment semantics are.

Here again I don't see that a Batch 2.0 -> 3.0 spec update is needed. 

The question that was not answered in today's call is what is the criteria for a dependency on another spec to trigger the following release of the dependee specification:

- service release

- minor update

- major update

For me, I would have the following criteria:

- service release; any update in the dependency could trigger an update to the artifact, but it is not required and there is no spec update.

- minor update; new minor features in the dependent spec are being made available via the dependee spec API and/or the specification is referring to those new minor features.

- major update; new major features in the dependent spec are being made available via the dependee spec API and/or the specification is referring to those new major features.