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.
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/dblevinshttp://www.tomitribe.com_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg