Re: [microprofile-wg] [Discussion] Context Propagation 1.3 Specification

[Emily Jiang <emijiang6@xxxxxxxxxxxxxx>]

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

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:

 - https://github.com/microprofile/microprofile-wg/labels/Plan%20Review

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