Scott, I think I agree with your criteria for minor and major updates:
- 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.
But my concern is with the server release criteria. For example, JTA-2.0.1 -> CDI-4.0. Would such a service release JTA API force CDI-4.0 to be used or would implementations be free to also support JTA-2.0.1 with CDI-3.0? I assume the TCK for EE 10 would only test compatibility with CDI-4.0.
I have a similar question for other specifications that are not doing any service release for EE 10 and have a dependency on CDI-3.0. I assume implementations of such specifications are free to support integrations with CDI-3.0 and CDI-4.0 implementations. Again, the TCK here for EE 10 would only test that integration with CDI-4.0 works as expected.
----- Original message -----
From: "Scott Stark" <starksm64@xxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] [jakartaee-platform-dev] Discussion of how dependencies trigger updates
Date: Tue, Nov 30, 2021 12:54 PM
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.
