Can’t speak for both WGs as I assume this would go through the various required votes. If MPWG is now looking to maintain backwards compatibility for api consumers e.g. jakarta for some specifications
that would be a positive change from previous “pull model” positions that needs to be considered.
Steve
From: cn4j-alliance <cn4j-alliance-bounces@xxxxxxxxxxx>
On Behalf Of Thomas Watson
Sent: 20 January 2021 19:28
To: cn4j-alliance@xxxxxxxxxxx
Subject: Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
Renaming an established API package never seems like a good idea to me. That should be the last option considered. Moving working groups to maintain
backwards compatibility also seems like the wrong precedent. MicroProfile should be able to be the home of their own "graduated" APIs. Now if we hear that MicroProfile is completely against maintaining compatibility going forward for future releases of MP
Config then we have more discussion that is needed. But lets assume MP Config spec maintainers in MicroProfile are willing to maintain backward compatibility going forward. Are there objections to such an approach in Jakarta?
----- Original message -----
From: Scott Stark <starksm64@xxxxxxxxx>
Sent by: "cn4j-alliance" <cn4j-alliance-bounces@xxxxxxxxxxx>
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
Date: Wed, Jan 20, 2021 12:17 PM
Yes, that is correct. The phrase in the charter is '... may break backwards compatibility'. The proving ground statement also gets to the issue of
not wanting to capriciously rename APIs that are in customer applications. When Jakarta wants to adopt an MP originated API, the first question has to be, who is going to support it, the second, how. At that point it can be decided whether that spec project
will be willing to introduce compatibility guarantees or whether it is willing to duplicate effort to keep the innovation aspect at a higher turnover than Jakarta is willing to accept.
Isn’t the MPWG charter explicit that backwards compatibility is not a goal of MP? I’d assumed that it was drafted that way on purpose along with “Experiment and Innovate” and “provides an industry
proving ground to incubate and experiment”?
It was from these charter principles and the strong desire from many to maintain WG independence that I suggested graduation to Jakarta EE in the first place.
Steve
Correct, and that is what I am trying to get an understanding of as well. I believe config is a strong candidate for a spec that has different handling relative to the default behavior in MP. I believe Red
Hat would vote for a change in handling on the MP side in order to use config on the Jakarta side. On the Jakarta side Red Hat would vote to not have to duplicate the effort that has already been put in.
The question is whether that could be a consensus view across the two WGs.
My understanding is that there are only a few MP APIs considered for inclusion in Jakarta APIs. Are there no MP APIs that would be considered for maintaining in a backward compatible way moving
forward within the MP working group? Does such a demand for backward compatibility make it such that the API cannot be evolved within the MP working group?
I'm still trying to understand what the two working groups are open to for a solution to using MP APIs in Jakarta specifications.
----- Original message -----
From: Scott Stark <starksm64@xxxxxxxxx>
Sent by: "cn4j-alliance" <cn4j-alliance-bounces@xxxxxxxxxxx>
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
Date: Tue, Jan 19, 2021 1:43 PM
Yes, many and APIs were not intended to ever transition to the JCP. Even with the transition of JCP to Jakarta, there remain process, cost and lifecycle issues that would cause Red Hat to target
MP over Jakarta.
_______________________________________________
cn4j-alliance mailing list
cn4j-alliance@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cn4j-alliance
|
