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