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.
Thanks
Emily
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
Thanks
Emily
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
--
--