Roadmap Evolution (Major vs Minor) meeting set up for Tuesday.

[John Clingan]

Given the amount of interest in the Roadmap and how to deal with backwards compatibility around major and minor versions, we decided to hold a one-off meeting on this topic at the same time this Tuesday. See the MicroProfile Calendar.

[Alasdair Nottingham]

I’ll have to provide my apologies for not being able to make it. It is a topic I’m very interested in, but alas I have a prior commitment I cannot get out of. I’ll talk to Kevin and Emily before hand since I’m sure they will be there.

Alasdair

On Apr 20, 2018, at 8:50 AM, John Clingan <jcli...@redhat.com> wrote:

Given the amount of interest in the Roadmap and how to deal with backwards compatibility around major and minor versions, we decided to hold a one-off meeting on this topic at the same time this Tuesday. See the MicroProfile Calendar.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d6086edd-af0a-48ed-8368-76b9e2536ca3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Clingan]

Alasdair, you have a 2nd chance :-)

Great progress(!) to all attendees the first meeting but it simply wasn't enough time. We have added a second roadmap meeting to the MicroProfile calendar for the same time this Thursday.

On Friday, April 20, 2018 at 6:41:54 AM UTC-7, Alasdair Nottingham wrote:

I’ll have to provide my apologies for not being able to make it. It is a topic I’m very interested in, but alas I have a prior commitment I cannot get out of. I’ll talk to Kevin and Emily before hand since I’m sure they will be there.

Alasdair

On Apr 20, 2018, at 8:50 AM, John Clingan <jcli...@redhat.com> wrote:

Given the amount of interest in the Roadmap and how to deal with backwards compatibility around major and minor versions, we decided to hold a one-off meeting on this topic at the same time this Tuesday. See the MicroProfile Calendar.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[John Clingan]

Egad, forgot to add link to meeting minutes:

https://docs.google.com/document/d/16v3jVkcDzVz9BVU5aGEzPVbK-a8BIx7S1gbqToVUaLs/edit#

[Emily Jiang]

Thank you John for organising the call! We had a great discussion on the major and minor change. I gave our rules a 2nd thought. I have some comments and would like to get some input from the wide community as well.



So far:

• Subspec rules (meaning MP Config, MP Fault Tolerence, MP Health etc)

• Adding a Jakarta EE specification at a higher Jakarta EE release level than is currently specified is a breaking change.

• Adding a Jakarta EE specification at the current Jakarta EE release level is a new feature, not a breaking change

• If subspec wants to make a breaking change, it must be in a new major version of the subspec (consistent with osgi semantic versioning).

• If we drop support for a Java version, it’s a breaking change.

• If we drop support for a Jakarta EE /  Java EE feature version, it’s a breaking change.

• A subspec can release a major version that includes breaking changes at any time and does not need to be coordinated with an umbrella spec.

• Subspecs have the ability to recommend which version of their spec should be included in a particular Umbrella release

• Subspecs have the ability to determine how many parallel release streams they maintain at any given time based on their resources, community interest, etc.

• This could become 0, resulting in the spec ending

I think the texts in red should not be the rules to make subspec e.g. MP Config to bump major version. It should a rule to control umbrella spec major bump.

Here are the reasons:
1. When a spec bumps major version, the consume does not know why? Has the APIs having a break change or what? Besides, when the support java version drops, the microservice itself does not need to be updated. What the major version message means to the end user?

2. The subspec should just focus on their APIs and version accordingly using OSGi semantic version. The implementors and consumers are clear about the changes.

3. In the past Java EE spec, the individual spec does not need to care about underline infrastructure. For example, JAX-RS 2.0 in EE7 (Java7+) and JAX-RS 2.1 in EE8 (Java 8 +).


The umbrella spec should communicate about minimum Java Version. If MP Config 1.4 needs to only work with CDI 2.0, it should go to MP 2.x where CDI 2.0 resides. In this way, it is nice and clean.

I deliberately copy and paste the minutes here to get all of your attentions. Once this is agreed, we will use these rules. It is very IMPORTANT to get it right. Please spend some time to think about this. Please join tomorrow's call if you can.

Thanks
Emily

 


On Tuesday, April 24, 2018 at 8:14:28 PM UTC+1, John Clingan wrote:

Egad, forgot to add link to meeting minutes:

https://docs.google.com/document/d/16v3jVkcDzVz9BVU5aGEzPVbK-a8BIx7S1gbqToVUaLs/edit#

On Tuesday, April 24, 2018 at 12:13:16 PM UTC-7, John Clingan wrote:

Alasdair, you have a 2nd chance :-)

Great progress(!) to all attendees the first meeting but it simply wasn't enough time. We have added a second roadmap meeting to the MicroProfile calendar for the same time this Thursday.

On Friday, April 20, 2018 at 6:41:54 AM UTC-7, Alasdair Nottingham wrote:

I’ll have to provide my apologies for not being able to make it. It is a topic I’m very interested in, but alas I have a prior commitment I cannot get out of. I’ll talk to Kevin and Emily before hand since I’m sure they will be there.

Alasdair

On Apr 20, 2018, at 8:50 AM, John Clingan <jcli...@redhat.com> wrote:

Given the amount of interest in the Roadmap and how to deal with backwards compatibility around major and minor versions, we decided to hold a one-off meeting on this topic at the same time this Tuesday. See the MicroProfile Calendar.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

[Scott Stark]

Practically, dropping support for a given Java version has to mean bumping up the minimum required, so that is how I would word it:

* If we increment the minimum required Java version, it's a breaking change.

The same for a Jakarta EE version:

* If we increment the minimum required Jakarta EE platform version, it's a breaking change.

You can practically drop support for a Jakarta EE feature, and that is a breaking change.

Adding a "Jakarta EE specification at the current Jakarta EE release level is a new feature" is only a non-breaking change at the MP platform spec level. In a subspec, this can be a breaking change as it is pulling in a new dependency that can result in CNFE or LinkageErrors depending on how types of the new spec are integrated into MP subspec.

[Ken Finnigan]

Emily,

I see all the items in red as being applicable to BOTH subspecs and the umbrella spec.

It would be entirely possible for a subspec to start incorporating features of Java EE 8, or Jakarta EE X, whenever they want, irrespective what the umbrella spec is doing. So long as their reasons for doing so make sense for them.

One important point that I don't think was raised yesterday, but that I feel is a consequence of what we discussed, is that each subspec becomes more like an independent project in their own right. Deciding what versions of JDK and Java EE/Jakarta EE they want to support, etc.

Now I still think there is a place for the umbrella group to make recommendations about what some of those should be, but in the end it's up to the subspec to decide what's best for them.

In response to your reason (1) below, I'm not sure I understand why this is a reason. If a subspec bumps a major version surely it's release notes would outline the reasons for that change?

I think your statement that "If MP Config 1.4 needs to only work with CDI 2.0, it should go to MP 2.x where CDI 2.0 resides" breaks semantic versioning doesn't it? If MP Config 1.3 -> 1.4 changes to rely on CDI 2.0 features, surely that should mean MP Config moves to 2.0?

Ken

[Alasdair Nottingham]

Doesn’t the “every spec can upgrade Jakarta EE versions independently” go against the “we should have an architecture group to ensure things are consistent”. 

I think this could make managing the umbrella releases quite difficult to manage and coordinate if one spec works with Jakarta EE 1 only and another prereqs Jakarta EE 2. Perhaps this is a non-existent problem, but we won’t really know ahead of time so I think having a more cautious approach to upgrading where specs don’t act unilaterally would be good. I think we need MicroProfile to function well together as if they are components of the same framework, or platform.

[Kevin Sutter]

Hi,
The MicroProfile subspec version discussion should clarify that we're referencing Java EE subspec verisons as well.  Not the Java EE platform spec version.  Somehow, we need to modify our wording to make this clear.

Using Ken's example...  If Config 1.3 introduces some changes that require CDI 2.0, then Config has to move to 2.0.  We're not talking about MP versions nor are we talking about Java EE versions at this point.  Just the "subspec" idea.

Thanks, Kevin

[Emily Jiang]

Scott,

>Practically, dropping support for a given Java version has to mean bumping up the minimum required, so that is how I would word it:

* If we increment the minimum required Java version, it's a breaking change.

>The same for a Jakarta EE version:

* If we increment the minimum required Jakarta EE platform version, it's a breaking change.

>You can practically drop support for a Jakarta EE feature, and that is a breaking change.

>Adding a "Jakarta EE specification at the current Jakarta EE release level is a new feature" is only a non-breaking change at the MP platform spec level. In a subspec, this can be a breaking change as it is pulling in a new dependency that can result in CNFE or LinkageErrors depending on how types of the new spec are integrated into MP subspec.

It depends. Dropping a minimum required Java version only breaks someone at the minimum Java version but not someone that are on higher Java version already.

Because of this, the Java version and Jakarta EE version should be managed by the umbrella release NOT the individual spec.

The umbrella release should take care of the infrastruct requirement not the individual specs.


Ken,

>

In response to your reason (1) below, I'm not sure I understand why this is a reason. If a subspec bumps a major version surely it's release notes would outline the reasons for that change?

This info should be carried by the umbrella spec. In this case, the specs contained within it do not need to repeat the same question over and over again but only list the API changes.

>I think your statement that "If MP Config 1.4 needs to only work with CDI 2.0, it should go to MP 2.x where CDI 2.0 resides" breaks semantic versioning doesn't it?

No, it does not break semantic versioning as the semantic versioning is for the spec APIs not the dependencies.


>If MP Config 1.3 -> 1.4 changes to rely on CDI 2.0 features, surely that should mean MP Config moves to 2.0? No, it can stay at 1.4 if itself has no breaking changes e.g no methods being updated/deleted from interfaces.


+1 on Alasdair's comments!

I am proposing this model:

Umbrella spec major version bumps

• Adding a Jakarta EE specification at a higher Jakarta EE release level than is currently specified is a breaking change.

• Adding a Jakarta EE specification at the current Jakarta EE release level is a new feature, not a breaking change

• If we drop support for a Java version, it’s a breaking change.

• If we drop support for a Jakarta EE /  Java EE feature version, it’s a breaking change.

The above rules should not bump subspec's major version but it makes the subspec ends up in a different umbrella release.

If we use the rules in red for both subspec and umbrella spec, the umbrella spec MP 2.0 will include MP Config 2.0, MP FT 2.0, ..... etc. This has caused subspec bumps its version unnecessarily. Besides, we said the subspec should be cautious when it comes to break backward compatibility. We will be contradict ourselves all the time with moving Java minimum support version and adopt Jakatar EE version.


Basically, I am trying to say we should take the Java EE umbrella version approach for the umbrella releases. For individual specs, we should just use OSGi semantic version policy to guard against APIs. For minimum Java version, dependency Jakarta EE version, they should be handled by the umbrella MP releases not affecting the major version of subspecs.

In this way, we can easily say, for the specs e.g. Config 1.4  only ending up in MP 2.0 not in MP 1.x, will only work with Java EE8 not with Java EE7.

Emily

[John Clingan]

Second meeting has now completed. Meeting minutes here. Youtube video being uploaded to MicroProfile Youtube channel.

[Alasdair Nottingham]

Hi,

I have attempted to write up the minutes in a single set of guidelines on the wiki. I created a page here: https://wiki.eclipse.org/MicroProfile/SpecVersioning it isn’t visible because it is awaiting moderation so if someone could moderate it I’d be grateful.

I know on the call we said we could start by copying in the minutes, but as I reviewed the minutes I felt there was a simpler way to write everything down so I have very much attempted to do that. I believe what I have written is consistent with the minutes, but I’ve tried to separate out what are guidelines for new version numbers vs what are more release/process guidelines. I’ve also attempted to mark things which are still being discussed.

If I haven’t correctly captured what was discussed I’m sorry it was not my intent to change what has been discussed or agreed.

Alasdair

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c628cb49-61fc-47f4-9e90-9846e6f8437b%40googlegroups.com.

[Kevin Sutter]

Alasdair, it's the Eclipseweb master that has to moderate and approve your post.  It's their way of preventing bots from generating wiki pages...  They will moderate your first post to ensure that your id is valid and then you will have normal access to updating the wiki.  Sorry for the inconvenience.  Eclipse rules...  :-)

--  Kevin

On Thu, Apr 26, 2018 at 3:55 PM, Alasdair Nottingham <alasdair....@gmail.com> wrote:

Hi,

I have attempted to write up the minutes in a single set of guidelines on the wiki. I created a page here: https://wiki.eclipse.org/MicroProfile/SpecVersioning it isn’t visible because it is awaiting moderation so if someone could moderate it I’d be grateful.

I know on the call we said we could start by copying in the minutes, but as I reviewed the minutes I felt there was a simpler way to write everything down so I have very much attempted to do that. I believe what I have written is consistent with the minutes, but I’ve tried to separate out what are guidelines for new version numbers vs what are more release/process guidelines. I’ve also attempted to mark things which are still being discussed.

If I haven’t correctly captured what was discussed I’m sorry it was not my intent to change what has been discussed or agreed.

Alasdair

On Apr 26, 2018, at 4:08 PM, John Clingan <jcli...@redhat.com> wrote:

Second meeting has now completed. Meeting minutes here. Youtube video being uploaded to MicroProfile Youtube channel.

On Friday, April 20, 2018 at 5:50:07 AM UTC-7, John Clingan wrote:

Given the amount of interest in the Roadmap and how to deal with backwards compatibility around major and minor versions, we decided to hold a one-off meeting on this topic at the same time this Tuesday. See the MicroProfile Calendar.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c628cb49-61fc-47f4-9e90-9846e6f8437b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/yMt_N0KQkek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/1F437269-ECCF-49C9-A726-B35E7EAC6A35%40gmail.com.

[Alasdair Nottingham]

I guess I hoped that the Eclipseweb master would have a rule that auto-approves if the change is made by a committer. I doubt very much a bot could get through that process.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CABH8er%3DK2ceC%3DN0gg5Y2RQ6iffR2bwULWK9k63bmZHxBXJ18Gw%40mail.gmail.com.

[Kevin Sutter]

Yep, we tried that argument when we first ran into this situation...  It used to be that you had to do 10 moderated changes before they would allow free reign.  When we got them down to one moderated change, we celebrated and moved on.  :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CABH8er%3DK2ceC%3DN0gg5Y2RQ6iffR2bwULWK9k63bmZHxBXJ18Gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/yMt_N0KQkek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/27655246-F5CF-4C75-A846-0F1977E14B74%40gmail.com.

[Alasdair Nottingham]

Hi,

The edits are now visible on the wiki: https://wiki.eclipse.org/MicroProfile/SpecVersioning

Alasdair

[John Clingan]

Thanks Alasdair, for taking the enviable role of meeting minutes interpreter :-)

I'll take a look.

On Monday, April 30, 2018 at 8:25:53 AM UTC-7, Alasdair Nottingham wrote:

Hi,

The edits are now visible on the wiki: https://wiki.eclipse.org/MicroProfile/SpecVersioning

Alasdair

On Apr 26, 2018, at 4:55 PM, Alasdair Nottingham <alasdair....@gmail.com> wrote:

Hi,

I have attempted to write up the minutes in a single set of guidelines on the wiki. I created a page here: https://wiki.eclipse.org/MicroProfile/SpecVersioning it isn’t visible because it is awaiting moderation so if someone could moderate it I’d be grateful.

I know on the call we said we could start by copying in the minutes, but as I reviewed the minutes I felt there was a simpler way to write everything down so I have very much attempted to do that. I believe what I have written is consistent with the minutes, but I’ve tried to separate out what are guidelines for new version numbers vs what are more release/process guidelines. I’ve also attempted to mark things which are still being discussed.

If I haven’t correctly captured what was discussed I’m sorry it was not my intent to change what has been discussed or agreed.

Alasdair

On Apr 26, 2018, at 4:08 PM, John Clingan <jcli...@redhat.com> wrote:

Second meeting has now completed. Meeting minutes here. Youtube video being uploaded to MicroProfile Youtube channel.

On Friday, April 20, 2018 at 5:50:07 AM UTC-7, John Clingan wrote:

Given the amount of interest in the Roadmap and how to deal with backwards compatibility around major and minor versions, we decided to hold a one-off meeting on this topic at the same time this Tuesday. See the MicroProfile Calendar.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[Kevin Sutter]

Thanks, Alasdair!  I think your wiki updates captures the minutes and discussion quite well.  We have this topic on our agenda for tomorrow's Bi-weekly MicroProfile Hangout...

https://calendar.google.com/calendar/embed?src=gbnbc373ga40n0tvbl88nkc3r4%40group.calendar.google.com

-- Kevin

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/yMt_N0KQkek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/dfcab661-762d-4a5f-ba24-63a58848a583%40googlegroups.com.

[Alasdair Nottingham]

I’m glad I did, I don’t know if I can make the call tomorrow since I’ll be out of the office for the hour immediately before, but I’ll do my best to join as soon as I can. 

Alasdair Nottingham

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CABH8er%3DK3oPBL_zfYBTPhDxiy7je1iYoBN7vaUtT8acYZgFeXQ%40mail.gmail.com.

[Emily Jiang]

I like what Alasdair did to differentiate slightly breaking changes items from major version updates, which should send a less alarming message to the consumers ( e.g. Java version, Jakarta EE or other spec dependencies are generally good things).


For the current pattern, all packages of each sub-spec(component spec) complies with OSGi semantic versioning, while the sub-spec overall version can carry the message of spec dependencies.

I might have been over worried about too many version upgrade, which causes managing release trains difficult to operate. I thought this a bit more. Actually, if we coordinate the major upgrade, Java version upgrade, Jakarta EE upgrade, we might be ok.

Let's continue our rules to define the umbrella spec. I would like to list a few scenario for discussion. It will be good if we look ahead the next 12 months release to see whether we can manage this.

Talk to you later.

Emily

Alasdair

Alasdair

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c628cb49-61fc-47f4-9e90-9846e6f8437b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/yMt_N0KQkek/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/dfcab661-762d-4a5f-ba24-63a58848a583%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[David Blevins]

Agreed.  It looks even better than the minutes.  Thank you, Alasdair!

-- 

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

310-633-3852

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CABH8er%3DK3oPBL_zfYBTPhDxiy7je1iYoBN7vaUtT8acYZgFeXQ%40mail.gmail.com.