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/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