Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [microprofile-wg] [DISCUSS] MicroProfile 7.0 Ballot verbiage straw poll
Hi Reza and David,

I think in the proposals discussion there is a lot of misunderstanding.

As I understands the goal of the proposals is to define releasing MP and take into account the fact, that Jakarta EE umbrella specs will (and must) be released before a MP umbrella spec can be released with having a dependency to that Jakarta version.
So the idea (of especially proposal 1) is to fill that potential time gap between the releases of the umbrella specs.

For vendors that want to support both umbrella specs, this can be an issue, as a final version of the implementation need to wait until the MP umbrella spec is released too.


To the facts:

Jakarta EE umbrella spec as planed release cadence of 1 per 2 years (and following 6 month on a Java SE LTS release, than should be supported).
The next release is planed for Q1 2023 and will be a Major Release, as it contains multiple breaking changes like minimum Java SE will be 21, drop of the security manager support, Jakarta REST Major Release (part of the Core Profile!), etc...

MicroProfile
A MicroProfile umbrella spec Major Release is planed for Q2 2023 currently (3 month time gap).

May be focusing on the facts and (architectural) design decisions would be helpful.

- Releation of


Am 20.05.23 um 04:58 schrieb reza_rahman@xxxxxxxxx:
As outlined in option 3, if the EE version being upgraded to does not contain breaking changes, then a minor release of MicroProfile suffices unless it has breaking changes on its own right. In your example, it would be 7.x.

If the EE version being upgraded to contains breaking changes (which in all practically what is going to happen for EE 11), then the MicroProfile release should be major. So it would not be 7.x but 8 in your example.

That’s what users have come to expect using Semantic Versioning and generally what we do at Microsoft, including backwards compatibility dynamics in our dependencies. It makes user expectations very simple.
 
From: microprofile-wg <microprofile-wg-bounces@xxxxxxxxxxx> on behalf of David Blevins <dblevins@xxxxxxxxxxxxx>
Sent: Friday, May 19, 2023 10:34 PM
To: Microprofile WG discussions <microprofile-wg@xxxxxxxxxxx>
Subject: Re: [microprofile-wg] [DISCUSS] MicroProfile 7.0 Ballot verbiage straw poll
 
This really helps and I greatly appreciate the answers.

> On May 19, 2023, at 6:47 PM, Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
>
> Responses in-line, extra text removed for brevity. I hope we can get to a productive path now.
>
> On 5/19/2023 9:14 PM, David Blevins wrote:
>> Are you proposing we release 7.0 with EE 10 as the requirement, then potentially release 7.1 with EE 11 as the requirement?
> RR: If 7.0/7.1 is released before EE 11, it should use EE 10. If either is released after EE 11, it should aim to use EE 11. That is what is outlined in option 3.

Understood, thanks. When EE 11 is released the proposal would be to release an updated 7.x that changes the required version from EE 10 to 11.

>> - do you see this as a breaking change?
> RR: It depends. Any MicroProfile release can introduce breaking changes on it's own right. If we upgrade to an EE version that contains a breaking change, we are transitively introducing a breaking change That is what is outlined in option 3.

This is the most helpful part — thank you. We can do this, but we’d need to change some policies we’ve had in place.

So far we’ve strictly disallowed breaking changes in minor releases. Component specification versions that have breaking changes have so far been not included in a MicroProfile umbrella release until the next major version. To date we have considered changing Java versions or EE versions as a breaking change as it means dropping support for the older Java or EE version which affects users and implementations.

If we want to use minor releases to address the issue, we’d need to update our policies so that we can either 1) have breaking changes in minor releases or 2) we no longer consider changing Java or EE versions as a breaking change.

Are you leaning more towards the #1 side where we do allow breaking feature changes in MP specifications between say 7.0 and 7.1, or are you more along the lines that #1 is bad, but #2 is not that terrible when there are no real breaking changes in the Java or EE dependencies?

>> - will MP 7.0 implementations that are based on EE 10 be able to implement 7.1 and claim certification?
> RR: It depends on whether 7 and 7.1 both depend on EE 10. If 7.1 upgrades to EE 11, then no. You will need to re-certify, hopefully with pretty minimal effort. That is what is outlined in option 3.

I think updating your product from EE 10 to 11 is not a minimal effort, but I appreciate the clarification.



--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

_______________________________________________
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

_______________________________________________
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


Back to the top