| Re: [microprofile-wg] [External] : [Discussion] Context Propagation 1.3 Specification Release Review |
Emily,
Thank you for starting a discussion 'side' thread. I didn't see that happen before so I didn't realize that was our custom.
I thought there had been other plan reviews for MicroProfile
component specifications, but I see that I was mistaken in that
impression. I would encourage us to adopt that in future releases
but I'm willing to concede this is not an issue for MP 5
specifications and I apologize for raising it as an concern for CP
1.3.
If the CP Specification truly has no dependencies on the Jakarta
EE components, I wonder if perhaps the TCK contains tests that are
beyond the scope of this Specification. I'd ask the development
team: Is there an Assertion that is traceable to the Specification
(text or Java Docs), tested in the TCK, that requires a specific
Jakarta EE version. If there is no such assertion, perhaps the
Jakarta EE version elements in the TCK are incorrect and should be
removed. If the Specification documentation does require a
specific version of Jakarta EE -- then, this test should remain.
This would be consistent with David's suggestion, but changing the
TCK, at least in my book -- is a change to the Specification, to
wit ...
I would encourage us to adopt the position that the Specification is ALL OF the written document (the Specification document and/or Java Docs), the Binary Artifacts (API JARs, etc), AND the TCK. These each provide important aspects of the Specification and any change to a component element, should be considered a change in the Specification.
In summary, if it is determined the CP 1.3 specification /does/
require Jakarta EE 9, I'd encourage us to communicate that
incompatibility to our users and fellow implementer groups by
designating this a major release, not a minor release. If EE 9 is
not a CP requirement, the minor version change is totally
appropriate and (probably) the TCK should omit those tests.
I apologize for raising this so far into this project program.
Thank you,
-- Ed
I have a suggestion on the voting thread. If there are comments related to the voting, I suggest we start a new thread so that the voting thread can stay focused with the voting.
I started this discussion thread to follow the discussion on Context Propagation 1.3 release.
As for MP Context Propagation 1.3, the spec and api are identical to MP Context Propagation 1.2. I would say the api and spec produced in MP Context Propagation 1.3 will work with either Jakarta EE 8 or Jakarta EE 9. In this context, the spec 1.3 is backward compatible with 1.2. In other words, if you drop MP Context Propagation 1.3 api jar in your Jakarta EE 8 runtime, it works without any problem.
If you want to run the certification, you can use the tck jar produced by MP Context Propagation 1.2, and use 1.3 for Jakarta EE 9. Therefore, you may not need to transform any jakarta or javax.
Does this address your question, Ed?
p.s For minor vs. major releases for Jakarta EE 9.1 alignment, we discussed this topic on one of our live hangouts (6th July). I asked the minor release vs. major release question and suggested we do a minor release for the specs with only tck dependencies on Jakarta EE. There were no objections.
ThanksEmily
On Tue, Nov 16, 2021 at 10:53 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
As for plan review, after MicroProfile Working Group was established in 2020, we started with a release view. We did not put the plan review in the process. We can revisit this in 2022. As a matter of fact, we will start using the Plan Creation Review for new specs (see here). We should follow the steps laid out by EFSP 1.3.
As for the minor vs major changes for Context Propagation, as mentioned in the release plan, the api jar has no dependencies on javax, this release is purely for any runtime that wishes to run its tcks using jakarta namespace. I think minor changes make sense.
Therefore, I think the top option as suggested by David makes sense.
- Keep the minor version change and:- be ok to accept CCRs from Jakarta EE 8 based impls that have used bytecode tools to modify the CP 1.3 TCK itself back to the 'javax' namespace
ThanksEmily
On Tue, Nov 16, 2021 at 9:15 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
_______________________________________________On Nov 16, 2021, at 12:38 PM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:1) Was there an approved plan review for Context Propagation 1.3? (I'm missing my record of that and apologize if I just lost this.)
Good callout. I think we've missed Plan Reviews in general:
We definitely need to do those from now on.
2) All the other specifications are making major releases due to the incompatible changes required by Jakarta 9.1. While the Context Propagation API may not have a direct dependency on Jakarta EE APIs, it seems the TCKs may. Is it confirmed this is a minor-release compatible update? Should a user running on Jakarta EE 8, expect to be able to upgrade their implementation to Context Propagation 1.3 successfully without also upgrading their Jakarta EE dependency? Should a vendor anticipate supporting both EE 8 and 9 with this release?
More good questions. I see that we did update the namespaces in the TCK.
I'd be hesitant to establish a rule where major changes in the TCK need to result in a major version change. That said, we're not talking strictly about changes in the TCK (say moving from Junit to TestNG) that do not have an impact on the server itself. The change in the TCK does require a change in the server and that creates some ambiguity in my mind.
Here are some potential resolutions that seem to make sense to me:
- Keep the minor version change and:- be ok to accept CCRs from Jakarta EE 8 based impls that have used bytecode tools to modify the CP 1.3 TCK itself back to the 'javax' namespace OR- issue our own javax version of the CP 1.3 TCK, which Jakarta EE 8 based impls can chose as an alternate to the jakarta namespace CP 1.3 TCK- Update the major version
Any other options people see?
-David
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
--
Thanks
Emily
--
Thanks
Emily
_______________________________________________ microprofile-wg mailing list microprofile-wg@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/microprofile-wg__;!!ACWV5N9M2RV99hQ!aCfm6YiQeQHxBhmhhCDpzGLmJTomRDQCuZEt_zsxVqArWY7qU0kaIdP4s7jv8eo$