Breaking Changes in MicroProfile platform releases...

156 views
Skip to first unread message

Kevin Sutter

unread,
Jan 8, 2019, 5:07:00 PM1/8/19
to microp...@googlegroups.com
Hi,
The topic of Component breaking changes and their effect on the Platform releases was discussed at today's MicroProfile hangout.

One of the Decisions proposed at this meeting was this:

    • DECISION:  Designate the June release as the MP Platform release that will accept breaking changes.  Components can introduce breaking change releases at any time, but can only be included in the platform in the June release


Please reference the Agenda/Minutes for Jan 08 and/or the Video to get the background.  (That is, let's not re-hash the same discussion via this post.)

I'm posting this decision to get a wider audience and to see if we have any dissension to this approach before this Decision gets approved at the next Hangout on the 22nd.

The reason for this discussion and decision is because we had a few MicroProfile components that were targeting a Major version update (breaking API changes) sometime in 2019.  Based on our Versioning rules which were adopted last year, if we include Component major version updates through out the year, it would require a Platform major version update with every release.  This could lead to "major version creep" where we might end up with three new MicroProfile Platform major releases this year (MP 3.x, MP 4.x, MP 5.x, etc).  Besides the optics of those increasing version numbers, it also introduces additional release streams to possibly support.

So, to that end, we proposed having a single designated MicroProfile Platform release each year in June that could entertain breaking API Component releases.  Components could still release the Breaking API major version updates, but they wouldn't be considered for inclusion into the Platform until this designated release in June.  We have already decided on three releases per year -- Feb, June, and Oct.  As we are finding out, the Feb release is just too early in the year to entertain major version updates.  And, the October release is too late in the year to have suitable implementations available before the fall conference season kicks in.  So, the June Release was selected as the happy medium.

Just to be clear, this does not preclude or stop the Components from releasing Breaking API updates before (or after) the June release.  For example, we are encouraging Metrics 2.0 to continue with their February release plans.  MicroProfile would just announce both MicroProfile 2.2 and Metrics 2.0 in Feb.  Then, in June, we would entertain the idea of doing a MicroProfile 3.0 release with Metrics 2.0 and any other Breaking API Component releases.

We had a good turnout on the Hangout today, but I know there were a few key individuals not able to attend.  We would appreciate the ability to finalize this discussion via this thread so that we could Approve this Decision on the 22nd Hangout.  Thanks!

Ondro Mihályi

unread,
Jan 9, 2019, 4:36:27 AM1/9/19
to Eclipse MicroProfile
Hi Kevin,

I wasn't able to attend the hangout therefore I appreciate that you posted this here.

I agree with the decision, it makes complete sense in the current context. It gives everybody the benefit of knowing when a new major version of an individual component could be accepted by the MicroProfile Platform.

Thanks to all that contributed to the decision.

Ondro

On Tuesday, January 8, 2019 at 11:07:00 PM UTC+1, Kevin Sutter wrote:
Hi,
The topic of Component breaking changes and their effect on the Platform releases was discussed at today's MicroProfile hangout.

One of the Decisions proposed at this meeting was this:

    • DECISION:  Designate the June release as the MP Platform release that will accept breaking changes.  Components can introduce breaking change releases at any time, but can only be included in the platform in the June release


Please reference the Agenda/Minutes for Jan 08 and/or the Video to get the background.  (That is, let's not re-hash the same discussion via this post.)

I'm posting this decision to get a wider audience and to see if we have any dissension to this approach before this Decision gets approved at the next Hangout on the 22nd.

The reason for this discussion and decision is because we had a few MicroProfile components that were targeting a Major version update (breaking API changes) sometime in 2019.  Based on our Versioning rules which were adopted last year, if we let Component major version updates through out the year, it would require a Platform major version update with every release.  This could lead to "major version creep" where we might end up with three new MicroProfile Platform major releases this year (MP 3.x, MP 4.x, MP 5.x, etc).  Besides the optics of those increasing version numbers, it also introduces additional release streams to possibly support.

donbo...@gmail.com

unread,
Jan 9, 2019, 11:05:52 AM1/9/19
to Eclipse MicroProfile
+1 - this makes a lot of sense to me.  It keeps our ability to make breaking changes (judiciously, when needed) on a predictable schedule but ensures MicroProfile overall doesn't become un-adoptable due to too much version churn.

Don

Arthur De Magalhaes

unread,
Jan 9, 2019, 2:27:34 PM1/9/19
to Eclipse MicroProfile
+1!   We are going to target MicroProfile OpenAPI 2.0 for the June train. =) 

Thanks,
Arthur

Ondro Mihályi

unread,
Jan 10, 2019, 2:45:43 AM1/10/19
to Eclipse MicroProfile
One thing that I'd like to be clarified. Breaking changes (increasing the major version of a spec) can come only during a June release and not later during the year, right?

E.g., if there's Config 1.4 included in a June release (let's say MP 3.0) and soon after Config 2.0 is released then it has to wait for another MP June release. That means that if a breaking change misses the June release it has to wait for another year. This is what I expect.

In that case, I would encourage spec teams to release breaking changes soon before MP June releases to catch it. If a June release is missed, I'd recommend to backport functionality to a previous major version and work with it until the next June release to avoid waiting one full year until new features catch another MP June release. So e.g. if Config 2.0 is released soon after MP 3.0, I would release Config 1.5 with all non-breaking 2.0 features, keep working on 1.x and then merge 1.x to 2.0 and release 2.1 before another MP June release.

Alternatively, specs could keep PRs with breaking changes open until it's clear that the new major release is going to catch the new MP major release. If it doesn't catch it, it's easier to revert a breaking change done recently than a change done before many other commits.

Sounds complicated I know ;-) But in short, I want to avoid delaying new features for one year only because some breaking change prevents a major release to be included in an MP release.

Ondro

st 9. 1. 2019 o 10:36 Ondro Mihályi <ondrej....@gmail.com> napísal(a):
--
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/uUgU28hJjqA/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/c66e88be-8e93-4ff7-a86d-a795ef2378b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Kevin Sutter

unread,
Jan 10, 2019, 12:24:12 PM1/10/19
to Eclipse MicroProfile
Correct understanding, @Ondro.  If Config 2.0 would come out after the June MicroProfile 3.0 release (per your example), then Config 2.0 would have to wait until the following June to be included in the next MicroProfile Platform release.  But, just to be clear for all readers...  This approach does not prevent Config (or any other component) to introduce major version updates in between the June releases.  Depending on usage, Config could even introduce a 2.0 and 2.x updates prior to being included in a Platform release.  In the same light, Config should continue to look at improving their interim releases in the MicroProfile 2.x stream.  For example, could some of the changes going into Config 2.0 be considered in a Config 1.x without the breaking API changes?  I think this proposal provides those type of options...

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

Ken Finnigan

unread,
Jan 10, 2019, 3:17:07 PM1/10/19
to MicroProfile
First off, thanks for discussing this in the meeting.

In terms of what the conclusion was, I have a few concerns with it.
  1. Having major versions of specifications released alongside the umbrella, but not part of the umbrella, will create confusion over what version should be used. Especially as everyone always wants to use the latest of something. It could even lead to lack of interest in an MP umbrella release knowing there's a breaking change coming in the future. Also, what are the expectations around such a separate major component version in terms of interoperation with other specifications? For instance, would Metrics 2.0 be expected to work with non breaking change versions of other specifications that are part of the umbrella?
  2. It creates two streams of development for a specification, and not by any choice to do so. One for the version that's part of the umbrella, and another for the new major version. To me that adds extra work and effort for those working on implementing the specifications, and not everyone has the resources to do so.
  3. Restricting breaking changes to once a year restricts the frequency of innovation. I agree we don't want every MP umbrella release to bump the major version, and where possible it would be advisable for specifications to align breaking changes to minimize how often the umbrella version is bumped, but restricting that to once a year is quite arbitrary. Doing so will stifle innovation within specifications until 6 months leading up to umbrella breaking change releases, as why would anyone want to develop a specification up to a year before it could be included in an MP release?
Ken

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/c66e88be-8e93-4ff7-a86d-a795ef2378b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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/a3ac91a2-5165-4a47-8f8a-54143ec03144%40googlegroups.com.

Emily Jiang

unread,
Jan 10, 2019, 6:38:20 PM1/10/19
to Eclipse MicroProfile
Hi Ken,

Good questions!

At the call, I mentioned the similar idea in your 3rd point about socializing among the specs to group the break changes into one releases. Arthur said that Open API 2.0 is targeting for June release. Since Config 1.4 is not going to make MP 2.2 train, at today's Config Hangout, we are planning to release MP Config 2.0 and target for June release.

Basically, I am trying to say: umbrella release set one release to allow break changes, which is a way to group major break changes. More like from top to bottom approach. I think it is doable.

You did bring up the point on compatibility between orphaned spec release e.g. Metrics 2.0 and MP 2.2. I think it is up to app servers to decide whether they want to implement the orphaned releases, which might make the orphaned spec release not been widely supported. If they do implement the orphaned specs, they will decide whether the orphaned spec works with other features in the umbrella spec.

To make the process simple, maybe it is better not to mention orphaned spec releases in MP umbrella release. App servers can decide what to do.

In the meanwhile, if possible, we should encourage spec releases to be included in MP umbrella release. The individual specs can do the following:

1. Not to introduce backward incompatible changes to Feb, Oct spec release
2. Create a separate backward incompatible branch and work on the changes for June release if the change is too big so that the work can start early.

In this way, the spec can release other features to MP umbrella release while targeting the break changes to a particular release.

I think even though we allow backward incompatibility. However, we should try our best not to introduce lightly. We should only do it if it is absolutely necessary. I think the backward incompatible changes should not occur too often.

As indicated by Ondro, I think any backward incompatible changes should be handled with care and the issue should be marked with a special tag (e.g 'break' tag). We should standardise the way on how to manage the break changes. I will bring this up for further discussion and come up with a standard in our next MP hangout.


My 2cents
Emily

Ken Finnigan

unread,
Jan 11, 2019, 8:47:18 AM1/11/19
to MicroProfile
On Thu, Jan 10, 2019 at 6:38 PM 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:
Hi Ken,

Good questions!

At the call, I mentioned the similar idea in your 3rd point about socializing among the specs to group the break changes into one releases. Arthur said that Open API 2.0 is targeting for June release. Since Config 1.4 is not going to make MP 2.2 train, at today's Config Hangout, we are planning to release MP Config 2.0 and target for June release.

Basically, I am trying to say: umbrella release set one release to allow break changes, which is a way to group major break changes. More like from top to bottom approach. I think it is doable.

I agree it's doable. However, I'm against arbitrarily saying only one breaking change release per year.

I'm fine with the premise of trying to group as many breaking changes of specifications into a single umbrella release, but I disagree that we should set a limit on how many times we do that a year. The target should be minimal breaking change releases per year, not one.

If we release MP 3.0 in June and suddenly the world changes in such a way that most specs need breaking changes, to me it doesn't make sense to wait a full year before being able to release a version of MP that supports this "new way" just because we've set a limit of one breaking change release a year. And I'd prefer we don't take the approach of "changing the rules" if something like that happens, as what's the point of defining rules if we're just going to break them all the time.
 

You did bring up the point on compatibility between orphaned spec release e.g. Metrics 2.0 and MP 2.2. I think it is up to app servers to decide whether they want to implement the orphaned releases, which might make the orphaned spec release not been widely supported. If they do implement the orphaned specs, they will decide whether the orphaned spec works with other features in the umbrella spec.

It's not as simple as saying the App Server can deal with it.

A breaking change version of a specification could likely introduce changes that prevent integration with existing MP specifications until they update to use some new SPIs. Making that work would require App Servers to develop wrappers/mappers to go from one to the other, all for something that is temporary.

More than that, it's the confusion for users/developers. If a user is starting to look at MP for the first time, they're going to want to use the latest of something to get a baseline, which causes confusion when some of those latest versions aren't actually part of an MP release.
 

To make the process simple, maybe it is better not to mention orphaned spec releases in MP umbrella release. App servers can decide what to do.

In the meanwhile, if possible, we should encourage spec releases to be included in MP umbrella release. The individual specs can do the following:

1. Not to introduce backward incompatible changes to Feb, Oct spec release
2. Create a separate backward incompatible branch and work on the changes for June release if the change is too big so that the work can start early.

In this way, the spec can release other features to MP umbrella release while targeting the break changes to a particular release.

As per my original response, I believe this approach stifles innovation and complicates the maintenance and development of an MP specification, in addition to the implementations of that specification.
 

I think even though we allow backward incompatibility. However, we should try our best not to introduce lightly. We should only do it if it is absolutely necessary. I think the backward incompatible changes should not occur too often.

I'm by no means advocating we break backward compatibility every release, but I'm concerned we're putting arbitrary limits in place that will unintentionally stifle innovation within specifications and hinder the "fast pace" MP has been able to maintain to date.
 

Kevin Sutter

unread,
Jan 11, 2019, 9:56:29 AM1/11/19
to Eclipse MicroProfile
Hi Ken,
Good discussion and fair points.  I'm just wondering how would we codify a different process?  Discussing each MP Platform release to see whether we would accept breaking changes isn't fair to the Component development teams.  They wouldn't know whether to allow for breaking changes or not.

Also, our users and customers of MicroProfile wouldn't know what to expect.  Let's pretend that we decided to bump MP 2.2 to MP 3.0 in Feb.  All of a sudden, our users will required to face breaking changes without much notice.  And, it could possibly introduce an opportunity for them to look elsewhere.  That is, instead of making the necessary changes for a breaking change, maybe they would look at alternatives.

Breaking changes are tough.  They really need to be thought through as to the impact to developers and users.  And, I don't equate breaking changes with innovation.  Innovation can come without introducing breaking changes.  But, given our fluid process with MicroProfile technologies, breaking changes are bound to be introduced at some point.  I just don't want every MicroProfile platform release to end up with breaking changes.  It will drive developers, users, and customers away.  We need to be judicial with introducing breaking changes.

As we were discussing the Versioning issue last year, we had determined that individual Components could go ahead with increasing their major version with breaking API changes.  But, the inclusion of those versions in the Platform release is not required:
  • A component spec can release a major version that includes breaking changes at any time and does not need to be coordinated with an umbrella spec.
This seems to be a decision of the Component and whether the additional complexity and support is worth the effort.  As an example, it looks like the Config team has decided to forego their 1.4 release for MP 2.2 and, instead, move towards a 2.0 release to be included in the MP 3.0 release.  So, based on this proposal, that team discussed the alternatives and decided it was better to wait.

You do bring a good point about interoperability between these breaking Component releases and the associated Platform release.  Regardless if they get released at the same time or not, it's still confusing.  How does Metrics 2.0 work with the rest of MicroProfile 2.2, for example?  If a user wants to try out Metrics 2.0, are they basically s-o-l with the rest of MicroProfile?  That wouldn't be very usable, would it?

Maybe we need to re-visit the numbering of the Platform releases...  And, instead of using semantic versioning for the Platform, we'll use "marketing versioning".  We increased from 1.x to 2.x when we changed our underling dependency from Java EE 7 to Java EE 8.  Maybe the next 3.x coincides with the support of Jakarta EE 8, and 4.x would be when Jakarta EE 9 comes out...  The MicroProfile Platform release would just become (stay?) a collection of interrelated Component releases, which may introduce Breaking Changes... 

Or, maybe we have to support older versions of the Component releases when a breaking change is introduced?  So, if MicroProfile 2.2 comes out with Metrics 2.0, then Metrics 1.x would also have to be supported in MP 2.2.  And, we would require this support to last at least one Platform release cycle?  This would allow developers and users to gradually move to the breaking change release.  And, yes, it puts more requirements on the Component to support both releases for some period of time, but they are introducing some breaking changes, so some pain has to be felt...

Sorry to be going all over the map here...  I'm just trying to throw out some ideas to get people thinking.

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

Ken Finnigan

unread,
Jan 11, 2019, 2:32:30 PM1/11/19
to MicroProfile
On Fri, Jan 11, 2019 at 9:56 AM Kevin Sutter <kwsu...@gmail.com> wrote:
Hi Ken,
Good discussion and fair points.  I'm just wondering how would we codify a different process?  Discussing each MP Platform release to see whether we would accept breaking changes isn't fair to the Component development teams.  They wouldn't know whether to allow for breaking changes or not.


Certainly we wouldn't want to leave determining whether an umbrella release will have breaking changes to the last minute before a release, that would be nasty. But I believe most specifications would have an idea reasonably early on in the development of their next release as to whether there is the possibility of breaking changes, which could then be raised with the wider group to discuss whether there are other specifications that might need breaking changes and whether the next umbrella should be a breaking change or not. Given the thrice yearly release schedule we've defined, it wouldn't be unreasonable to set a date 2-3 months before the release to make such a decision.
 
Also, our users and customers of MicroProfile wouldn't know what to expect.  Let's pretend that we decided to bump MP 2.2 to MP 3.0 in Feb.  All of a sudden, our users will required to face breaking changes without much notice.  And, it could possibly introduce an opportunity for them to look elsewhere.  That is, instead of making the necessary changes for a breaking change, maybe they would look at alternatives.

For now I'm discounting the February release from the bumping discussion, as I agree it's too close to change anything for that.
 

Breaking changes are tough.  They really need to be thought through as to the impact to developers and users.  And, I don't equate breaking changes with innovation.  Innovation can come without introducing breaking changes.  But, given our fluid process with MicroProfile technologies, breaking changes are bound to be introduced at some point.  I just don't want every MicroProfile platform release to end up with breaking changes.  It will drive developers, users, and customers away.  We need to be judicial with introducing breaking changes.

Certainly innovation can happen without breaking changes, but it is constrained if there are severe limitations on breaking changes.

Though the specifications might advance at a fast pace, implementors of the specifications can "soften the blow" to developers and customers by supporting multiple umbrella versions, providing migration paths, not updating to every umbrella version and thus requiring changes immediately, or other methods to help with the transitions.
 

As we were discussing the Versioning issue last year, we had determined that individual Components could go ahead with increasing their major version with breaking API changes.  But, the inclusion of those versions in the Platform release is not required:
  • A component spec can release a major version that includes breaking changes at any time and does not need to be coordinated with an umbrella spec.
This seems to be a decision of the Component and whether the additional complexity and support is worth the effort.  As an example, it looks like the Config team has decided to forego their 1.4 release for MP 2.2 and, instead, move towards a 2.0 release to be included in the MP 3.0 release.  So, based on this proposal, that team discussed the alternatives and decided it was better to wait.


I remember we did agree to that, but thinking about the Metrics 2.0 situation for February I've begun to think that it's not a practical way to move forward. What happens if we have 4 or 5 specifications releasing a new version, breaking changes or not, that for whatever reason isn't included in an umbrella release? It would be incredibly confusing for users to understand what they should be using.
 
You do bring a good point about interoperability between these breaking Component releases and the associated Platform release.  Regardless if they get released at the same time or not, it's still confusing.  How does Metrics 2.0 work with the rest of MicroProfile 2.2, for example?  If a user wants to try out Metrics 2.0, are they basically s-o-l with the rest of MicroProfile?  That wouldn't be very usable, would it?

That's where I'm at right now. Though it's a flexible approach for specifications, it's not entirely practical from an overall MP perspective.
 

Maybe we need to re-visit the numbering of the Platform releases...  And, instead of using semantic versioning for the Platform, we'll use "marketing versioning".  We increased from 1.x to 2.x when we changed our underling dependency from Java EE 7 to Java EE 8.  Maybe the next 3.x coincides with the support of Jakarta EE 8, and 4.x would be when Jakarta EE 9 comes out...  The MicroProfile Platform release would just become (stay?) a collection of interrelated Component releases, which may introduce Breaking Changes... 


Continuing with the current trend of MP majors being marketing releases is certainly an option. The biggest downside being that breaking changes can appear in specifications under the same major which could be confusing for developers.
 
Or, maybe we have to support older versions of the Component releases when a breaking change is introduced?  So, if MicroProfile 2.2 comes out with Metrics 2.0, then Metrics 1.x would also have to be supported in MP 2.2.  And, we would require this support to last at least one Platform release cycle?  This would allow developers and users to gradually move to the breaking change release.  And, yes, it puts more requirements on the Component to support both releases for some period of time, but they are introducing some breaking changes, so some pain has to be felt...

Though the idea is sound, i'm not sure how practical it will be, especially if SPI integration with other specifications has altered between the versions.

It also adds complexity for implementors, not just the specification.
 

Sorry to be going all over the map here...  I'm just trying to throw out some ideas to get people thinking.

Not at all, I appreciate your comments. Unfortunately I don't think there's a "great" solution, but just finding the one with the least number of drawbacks.
 
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.

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

Kevin Sutter

unread,
Jan 15, 2019, 5:28:11 PM1/15/19
to Eclipse MicroProfile
Ken,
I'm beginning to think that allowing out-of-band "breaking API" Component releases is not a great idea...  As we have been discussing, allowing these type of Releases complicates the environments -- development, support, implementations, and runtimes.  Unless we would state that any out-of-band Component releases would have to be compatible with the current Platform release...  For example, Metrics 2.0 would have to be compatible with MicroProfile 2.2.  But, even this introduces complexities...

So, let's pretend that we're not going to allow out-of-band "breaking API" Component releases...  When do these get introduced into the Platform release?  The proposal on the table is the June release.  Your argument is that this might stifle innovation.  It might actually stimulate innovation if the team knows there may be several months before they can introduce a "breaking API" change...  The plus side is that this is very predictable.  If breaking changes are being introduced into the Platform release, it will be in the June release.

If we're going to be flexible on which Platform release can contain breaking changes, then how much advance warning is required?  Is 6 months sufficient?  We're talking about the June 2019 release as allowing breaking changes, is 6 months sufficient notice?  Or, do we need to allow for 10 months -- the Oct release?  I'm thinking 6 months is sufficient.  One thing, there is only 4 months between our releases.  So, any discussion of breaking changes would have to be discussed with the wider team while the current release is being developed.  Teams couldn't wait until a Platform release is done and then decide that the next Platform release will also contain breaking changes, since that would only be 4 months.

Another idea is to indicate that every other Platform release could be entertained with breaking changes.  Thus, if we go ahead with a June 2019 release with breaking changes, then the next possible Platform release with breaking changes would be the Feb 2020 release.  Followed by the Oct 2020 release. Not that everyone of these releases have to to contain breaking changes, but these are the ones that we would allow them.  I kind of like this one since it's more predictable.  And, it doesn't limit breaking change Platform releases to just the June releases (depending on when we start this process).

There was a lot of discussion on this topic on the Hangout...  It sure would be good to get some alternate views and ideas posted here so that we could have an alternate proposal for next Tuesday's call... 

Thanks!
Kevin
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/bd3ea241-4850-488d-b5b4-2d2e081d6fe0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Emily Jiang

unread,
Jan 15, 2019, 6:18:26 PM1/15/19
to Eclipse MicroProfile
Kevin,

I was thinking about this earlier today. I do worry the compatibility and adoption for the existing spec released as a standalone release. e.g. Metrcis 2.0. It is released along with MP 2.2, how much tests will be needed to ensure everything is ok. This is tricky and different app servers have to handle differently. The MP starter will not be able to generate code against Metrics 2.0 as it gears towards umbrella release. I think if we do a standalone release for the existing specs, the adoption is not as easy as before. With this, I suggest not to do standalone release along side umbrella release. If a spec wants to release outside the release cycle, it is fine but we should not formally announce this release. With this in mind, I checked with Don today and he said they don't plan to release Metrics 2.0 in Feb release any more as they need to do a few more issues.

We are just lucky this time. In this case, umbrella release MP 2.2 can just go ahead to include the new releases of FT, Open Tracing, Open API, Rest Client.

Another idea is to indicate that every other Platform release could be entertained with breaking changes.  Thus, if we go ahead with a June 2019 release with breaking changes, then the next possible Platform release with breaking changes would be the Feb 2020 release.  Followed by the Oct 2020 release. Not that everyone of these releases have to to contain breaking changes, but these are the ones that we would allow them.  I kind of like this one since it's more predictable.  And, it doesn't limit breaking change Platform releases to just the June releases (depending on when we start this process).

I think June release is a major release, which makes sense. I am not sure about Feb 2020, Oct 2020 containing breaking changes. It might not be a good thing to release too many containing breaking changes in one year. I think one of those is manageable. More than one might send a different signal as unstable.  At least we are settled for Feb 2019 release, let's talk more next week on this.

My 2cents.
Emily
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.

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

Ken Finnigan

unread,
Jan 16, 2019, 2:41:06 PM1/16/19
to MicroProfile
Kevin,

Comments inline.

On Tue, Jan 15, 2019 at 5:28 PM Kevin Sutter <kwsu...@gmail.com> wrote:
Ken,
I'm beginning to think that allowing out-of-band "breaking API" Component releases is not a great idea...  As we have been discussing, allowing these type of Releases complicates the environments -- development, support, implementations, and runtimes.  Unless we would state that any out-of-band Component releases would have to be compatible with the current Platform release...  For example, Metrics 2.0 would have to be compatible with MicroProfile 2.2.  But, even this introduces complexities...

I'm reaching the same conclusion, it simply introduces too much complexity.

Could be restated as "MicroProfile component releases that won't be part of an upcoming umbrella release, can only be made by components that don't already have a release in a previous umbrella release". Basically saying that exploratory components, like Reactive in the beginning, and LRA, etc, can release outside an umbrella release, but once you're part of the umbrella any new release must be put up for consideration in the next umbrella release. Now, at the umbrella level we may still decide we don't want to include a new release of a spec for a particular reason, but it wouldn't be then advertised and usable with that umbrella release.
 

So, let's pretend that we're not going to allow out-of-band "breaking API" Component releases...  When do these get introduced into the Platform release?  The proposal on the table is the June release.  Your argument is that this might stifle innovation.  It might actually stimulate innovation if the team knows there may be several months before they can introduce a "breaking API" change...  The plus side is that this is very predictable.  If breaking changes are being introduced into the Platform release, it will be in the June release.

If we're going to be flexible on which Platform release can contain breaking changes, then how much advance warning is required?  Is 6 months sufficient?  We're talking about the June 2019 release as allowing breaking changes, is 6 months sufficient notice?  Or, do we need to allow for 10 months -- the Oct release?  I'm thinking 6 months is sufficient.  One thing, there is only 4 months between our releases.  So, any discussion of breaking changes would have to be discussed with the wider team while the current release is being developed.  Teams couldn't wait until a Platform release is done and then decide that the next Platform release will also contain breaking changes, since that would only be 4 months.

Another idea is to indicate that every other Platform release could be entertained with breaking changes.  Thus, if we go ahead with a June 2019 release with breaking changes, then the next possible Platform release with breaking changes would be the Feb 2020 release.  Followed by the Oct 2020 release. Not that everyone of these releases have to to contain breaking changes, but these are the ones that we would allow them.  I kind of like this one since it's more predictable.  And, it doesn't limit breaking change Platform releases to just the June releases (depending on when we start this process).


I agree that 4 months isn't sufficient time for all components to know whether they're in a position, or want, to release a breaking change release. 6 months certainly seems more reasonable.

With respect to timing, I thought the idea of alternating platform releases for breaking changes would work. But then I realized by virtue of our 3 releases a year, it gives us a fixed one breaking change release in a year, two in the next, then one in the next, and so on. Essentially a fixed schedule. I'm also thinking that two a year every second year is too much.

I was thinking through some alternatives to enable some flexibility without creating a large number of major umbrella versions, and came up with the following.

Limiting the major umbrella releases to one a year, except in the case of a MicroProfile wide change that is critical in which case it would be two a year. What I mean by MicroProfile wide change are things like updating to new Jakarta EE version, which impacts all specifications, or a dramatic shift industry wide that MicroProfile needs to move to or be left behind. In essence it really means one breaking change a year, and occasionally a second.

In terms of when that one breaking change release occurs I propose that it's somewhat floating, but needs to be agreed 6 months prior to an umbrella release date. Idea being that if by August there are components wanting to make breaking changes, we can decide to do so in Feb release. If none at that time, if by December components want to make breaking changes, we decide to do it in June release. If none at that time, if by April components want to make breaking changes, we do it in October release. Otherwise there are no breaking changes that year.

Not sure if that's better, worse, or on par with the fixed June breaking change release per year. Trying to think of ways to be somewhat flexible without adding complication
 
There was a lot of discussion on this topic on the Hangout...  It sure would be good to get some alternate views and ideas posted here so that we could have an alternate proposal for next Tuesday's call... 

Agree we need input from other members of the community.
 
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.

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

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

Kevin Sutter

unread,
Jan 17, 2019, 5:56:44 PM1/17/19
to Eclipse MicroProfile
Ken,
Let me see if I can summarize our discussion and propose an alternate Decision for next week's hangout...

  • MicroProfile plans for three releases each year (Feb, June, and Oct).  (Nothing new here, just clarifying.)
  • The MicroProfile 3.0 Platform release in June 2019 will allow breaking API changes from the Components (ie. Metrics 2.0, Config 2.0, and Health Check 2.0).
  • The next MicroProfile Platform release that allows breaking API changes needs to be declared six months in advance to allow for sufficient reaction (development, users, support, vendors, etc).  For example, starting a discussion in July for creating a breaking API Platform release in Oct won't fly (only 4 months).
As you said, this may end up with a Breaking API release every June anyway, but it does allow us to be flexible if the market suddenly changes.

I think that takes care of the Platform releases.  If that's considered flexible enough, maybe we don't have to worry about out-of-band Component breaking API changes?  That is, we have the upcoming June release to contain the currently defined major upgrades (ie. Metrics 2.0, Config 2.0, and Health Check 2.0).  And, we can declare future Platform breaking API change releases as needed.  So, maybe out-of-band Component releases are not an issue any more?

-- Kevin
Kevin,

Comments inline.

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/bd3ea241-4850-488d-b5b4-2d2e081d6fe0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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/e322d4c5-3575-40c2-bd43-91be761fcd92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Ondro Mihályi

unread,
Jan 18, 2019, 4:40:23 AM1/18/19
to MicroProfile
To complement Kevin's summary, I suggest that
  • We have at most one breaking change per year. If more are needed, we should have a thorough discussion and wide consensus about it.
  • A breaking change is planned in June by default. If we need to add breaking changes to another release, we should still try to keep roughly one breaking release per year as stated in the above point (either postpone breaking changes from a June release to another release or avoid breaking changes in the next June release or have more breaking releases after a wide consensus)

I think the struggle is between simplicity/transparency on one side and flexibility on the other side.

For me, it makes a lot of sense to focus on simplicity and agree to plan a breaking change release for June by default. So everybody would expect breaking changes to concentrate in June release. Individual components could count on it and postpone their breaking changes to a later release and avoid bumping the release version too early. The case with release Metrics 2.0 along with MP 2.2 wouldn't even happen if the Metrics team would know that the June release is a better target for their breaking changes.

I also understand that sometimes a breaking change in individual components is required sooner. I'm not against this, but I would really question the value of a breaking change in an individual component if it's not planned together with a breaking version of the MP umbrella. Most of the time, MP components aren't used individually outside of a MicroProfile container, even if some libraries allow it. If components release a breaking version ad hoc, it isn't very usable and adopted until it becomes part of the umbrella. On the other side, I think that having breaking changes in MP umbrella more frequently than once a year isn't very usable either because it confuses users and also complicates the work of implementors.

-- Ondro

št 17. 1. 2019 o 23:56 Kevin Sutter <kwsu...@gmail.com> napísal(a):
Kevin,

Comments inline.

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.

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

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

--
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/uUgU28hJjqA/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/27df39ed-e6f7-4832-b355-c59efa13eb0c%40googlegroups.com.

Ken Finnigan

unread,
Jan 18, 2019, 8:41:51 AM1/18/19
to MicroProfile
Kevin, great summary as it captures the points nicely.

With respect to the out-of-band component releases, it's probably fine that they exist but we need to make clear that there's absolutely no guarantees about compatibility with MP releases, marketing of them, or the like. It's more a "stake in the ground" on future direction of a component.

Ondro, your points are more inline with the original discussion in the Hangout than Kevin's summary, and also appear to be somewhat contradictory.

Ondro Mihályi

unread,
Jan 18, 2019, 9:49:46 AM1/18/19
to MicroProfile
Hi Ken,

I think I misunderstood Kevin's summary a bit, I realized it thanks to your comment. I assumed that the June release will be always accepting breaking changes and we can have other releases to accept them too. Now I understand that the June release shouldn't be any special and we should discuss every breaking release separately and decide on it 6 months before it.

I'm fine with that. I still believe that having more than one breaking release a year doesn't make much sense. But having to discuss this 6 months before a release is a sufficient barrier to believe that this would happen only rarely anyway.

I would just suggest one more point to reduce the bureaucracy:

  • a June release would automatically accept breaking changes if there was no breaking release in the past year. This could be just announced to simplify the process and allow breaking changes to happen at least once a year without too much discussion. Of course, if somebody would raise objections, we would start a discussion and treat it like any other release
Just a suggestion, I'm not keen on following it.

-- Ondro

pi 18. 1. 2019 o 14:41 Ken Finnigan <k...@kenfinnigan.me> napísal(a):

Ken Finnigan

unread,
Jan 18, 2019, 11:34:10 AM1/18/19
to MicroProfile
No problem Ondro, glad it's understood now.

With respect to your point below, how would that work in practice? Would it bump the major version even if there were no breaking changes from component releases? My initial thought is it seems a bit arbitrary.

Ken

Ondro Mihályi

unread,
Jan 18, 2019, 2:31:09 PM1/18/19
to MicroProfile
Hi Ken,

A bump to a new major version would not be necessary if there are no breaking changes. We would just do a simple check let's say a month before the June release and if no spec plans breaking changes, the MP major version would remain the same. But there would be a huge shift in thinking about breaking changes, on one side a breaking change release (major version increase) is planned 6 months in advance after a discussion (regular release) and on the other side a major version is expected to increase automatically and only month before it evaluated if we have any breaking changes to increase it (a June release at least a year after a previous new major release).

So at least once a year it would be easier to get a new major version without planning too much in advance and that's the only advantage I seek.

I understand this may introduce havoc in marketing planning because we would know if we increase the major version just a month before the release. So I'm OK if we put this idea on a shelf and maybe later think about it if we find the currently proposed process too cumbersome to introduce a new major release.

-- Ondro

pi 18. 1. 2019 o 17:34 Ken Finnigan <k...@kenfinnigan.me> napísal(a):
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe4_31Dc7Q6_1p4sxJ3Smu7mBSDN%2B%2BpzA3qx2XPGBKrarg%40mail.gmail.com.

Ken Finnigan

unread,
Jan 18, 2019, 2:36:13 PM1/18/19
to MicroProfile
Thanks for clarifying the idea.

From my perspective I think it makes it too confusing that we'd have a 6 mth lead time for a breaking change MP release, except when there were no breaking changes the previous year and then it could happen in June with one month notice.

Others may have a different view on that than me though

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CACZTZYUun7p0R-CBaUCmzqS5k1NxDps0tT%2BFSYDkXrRgr8zV8g%40mail.gmail.com.

Ondro Mihályi

unread,
Jan 18, 2019, 2:47:09 PM1/18/19
to MicroProfile
It wouldn't be confusing if we have a rule that this is announced 6 months before the June release. The difference is that it's enough if somebody remembers this, notifies the project lead and she/he announces on the mailing list that the next June release accepts breaking changes. No need to discuss, only announce. The discussion can happen 1 month before that release.

I guess what I'm afraid is that 6 months may be too long to plan for some cases. It might be even less flexible than planning breaking changes for every June release in some cases. Imagine that a spec is discussing a solution for 3 months, finally, they agree that the best thing is to break the API, then it takes time to discuss that we'll make a breaking change in the umbrella release, and then we need to wait at least 6 months (it may as well be 10 months - 6 months lead time minus one day to a release plus 4 months until the next release). So in the end, to indroduce a breaking change can easily take 12 months if we're unlucky. If we always planned breaking changes for a June release it could take 12 months (in some cases even 14 months) but it also could take only 3 months if we start working on a breaking change in March and finish it in May.

Introducing the possibility to add breaking changes in June without too much planning could decrease the time to get a breaking change out a lot. In the worst case it would be the same as with the 6 month lead period but in the best case it could be 3 months. If we don't have this option, it would always be at least 9 months roughly.

pi 18. 1. 2019 o 20:36 Ken Finnigan <k...@kenfinnigan.me> napísal(a):
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe5M0%3DFwQELBtovV4Uz_D4xjXTdK%2B3M6W%3DJ%3DezYkqYaNsw%40mail.gmail.com.

Ken Finnigan

unread,
Jan 18, 2019, 3:07:44 PM1/18/19
to MicroProfile
On Fri, Jan 18, 2019 at 2:47 PM Ondro Mihályi <ondrej....@gmail.com> wrote:
It wouldn't be confusing if we have a rule that this is announced 6 months before the June release. The difference is that it's enough if somebody remembers this, notifies the project lead and she/he announces on the mailing list that the next June release accepts breaking changes. No need to discuss, only announce. The discussion can happen 1 month before that release.

I'm not sure I understand this.

If 6 months before a release we've decided it can be a breaking change release, that will be defined in the planning such that everyone is aware it can be breaking. I don't understand what you mean by somebody remembering we agreed to a breaking release and then another discussion happening a month before the release. What's that discussion a month before doing?
 

I guess what I'm afraid is that 6 months may be too long to plan for some cases. It might be even less flexible than planning breaking changes for every June release in some cases. Imagine that a spec is discussing a solution for 3 months, finally, they agree that the best thing is to break the API, then it takes time to discuss that we'll make a breaking change in the umbrella release, and then we need to wait at least 6 months (it may as well be 10 months - 6 months lead time minus one day to a release plus 4 months until the next release). So in the end, to indroduce a breaking change can easily take 12 months if we're unlucky. If we always planned breaking changes for a June release it could take 12 months (in some cases even 14 months) but it also could take only 3 months if we start working on a breaking change in March and finish it in May.

Not picking on MP Health, but I took a look at [1] and [2] to get an idea of timelines as a comparison.

[1] was originally created in July 2017, but essentially lay dormant until June 2018 where discussion picked up again. From the discussion recommencing, it was in September 2018 that [2] was first created to provide an implementation for [1]. I believe [2] is now getting very close to the point of being accepted and merged, which introduces the breaking changes to MP Health.

Based on the above, from initial discussion of a change that could lead to breaking changes to the change actually being implemented it's been 6 months, at a minimum. From that perspective I don't think the guidelines that Kevin summarized are a burden.

I would also add, I don't see a problem with a specification saying 6 months before a release "we think we will have a breaking change for that release", and then in 2 months after further investigation they can come back and say that either it's no longer a breaking change, or that it won't be ready for that release. We could then decide whether there were other specifications that announced breaking changes, and if not then that release no longer becomes breaking.

 

Heiko Rupp

unread,
Jan 22, 2019, 5:09:47 AM1/22/19
to Eclipse MicroProfile
The whole thread grew into a bit of a tl;dr for me :)

From the Metrics 2.0 standpoint - and I think from the one of every component that wants to introduce a breaking change, it would be good if the new version could be made available for testing by users. Of course this can be done via Snapshots or endless series of CR releases. But very often implementors (other than the ones that create the version that is needed for the TCK testing) are not keen on implementing non-final spec releases.
What I want to say here is that Metrics (as example) should still be allowed to release a 2.0 at some point in time even if it will not be part of the umbrella at this time. 
One can defer the selection of the implementation to the implementing runtime (e.g. TT could ship with Metics 1.x as default for MP 2.2, but allow to pull in the SR-Metrics-2.0 version for the curious user). But still this requires that the umbrella spec allows it and does not forbid such a stunt as incompatible (as Java EE did in the past).

Ondro Mihályi

unread,
Jan 22, 2019, 7:42:22 AM1/22/19
to MicroProfile
Hi Heiko,

I think we've agreed that's OK to include a newer version in an MP impl as long as there are no breaking changes. If there are breaking changes, then it obviously wouldn't pass the TCK. Then it's up to the vendor to do what they want but it's not correct to say that a server provides MP 2.2 if it includes a breaking change from Metrics 2.0. At that point, the vendor should at least clearly document it. If there are no breaking changes, then it should be OK. The only kind of certification now is passing the TCK.

However, if Metrics 2.0 is released and not included in MP, also all the non-breaking changes would have to wait until an MP release that allows breaking changes. This is basically the problem we discuss here. Do we want then such spec to wait until it's included in MP? Or The spec should rather backport non-breaking changes and keep 2 parallel branches? What we're trying to achieve is that the spec doesn't have to maintain 2 parallel branches and still be included in MP as soon as possible.

-- Ondro



ut 22. 1. 2019 o 11:09 'Heiko Rupp' via Eclipse MicroProfile <microp...@googlegroups.com> napísal(a):
--
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/uUgU28hJjqA/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/b359c7fa-513d-4313-8f9a-8f7a72027cca%40googlegroups.com.

Kevin Sutter

unread,
Jan 22, 2019, 10:16:11 AM1/22/19
to Eclipse MicroProfile
Hi,
Reminder to everyone that this will be discussed on today's Google Hangout.  Please attend if you have an interest in finalizing this Decision (cross your fingers)!

Even after all of the discussion between Ken and Ondro, I think my summary from last Thursday is still accurate:
  • MicroProfile plans for three releases each year (Feb, June, and Oct).  (Nothing new here, just clarifying.)
  • The MicroProfile 3.0 Platform release in June 2019 will allow breaking API changes from the Components (ie. Metrics 2.0, Config 2.0, and Health Check 2.0).
  • The next MicroProfile Platform release that allows breaking API changes needs to be declared six months in advance to allow for sufficient reaction (development, users, support, vendors, etc).  For example, starting a discussion in July for creating a breaking API Platform release in Oct won't fly (only 4 months).
We do not want to require a Platform Breaking API release every year, but we will allow a Platform Breaking API release each year.  I still don't believe that we should be encouraging Breaking API changes.  But, in an innovative environment like MicroProfile, they are bound to happen.  If or when they are introduced, I think the above guidelines allow us a process for incorporating them into a Platform release at some point.

-- Kevin

On Tuesday, January 22, 2019 at 6:42:22 AM UTC-6, Ondro Mihályi wrote:
Hi Heiko,

I think we've agreed that's OK to include a newer version in an MP impl as long as there are no breaking changes. If there are breaking changes, then it obviously wouldn't pass the TCK. Then it's up to the vendor to do what they want but it's not correct to say that a server provides MP 2.2 if it includes a breaking change from Metrics 2.0. At that point, the vendor should at least clearly document it. If there are no breaking changes, then it should be OK. The only kind of certification now is passing the TCK.

However, if Metrics 2.0 is released and not included in MP, also all the non-breaking changes would have to wait until an MP release that allows breaking changes. This is basically the problem we discuss here. Do we want then such spec to wait until it's included in MP? Or The spec should rather backport non-breaking changes and keep 2 parallel branches? What we're trying to achieve is that the spec doesn't have to maintain 2 parallel branches and still be included in MP as soon as possible.

-- Ondro



ut 22. 1. 2019 o 11:09 'Heiko Rupp' via Eclipse MicroProfile <microp...@googlegroups.com> napísal(a):
The whole thread grew into a bit of a tl;dr for me :)

From the Metrics 2.0 standpoint - and I think from the one of every component that wants to introduce a breaking change, it would be good if the new version could be made available for testing by users. Of course this can be done via Snapshots or endless series of CR releases. But very often implementors (other than the ones that create the version that is needed for the TCK testing) are not keen on implementing non-final spec releases.
What I want to say here is that Metrics (as example) should still be allowed to release a 2.0 at some point in time even if it will not be part of the umbrella at this time. 
One can defer the selection of the implementation to the implementing runtime (e.g. TT could ship with Metics 1.x as default for MP 2.2, but allow to pull in the SR-Metrics-2.0 version for the curious user). But still this requires that the umbrella spec allows it and does not forbid such a stunt as incompatible (as Java EE did in the past).

--
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/uUgU28hJjqA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

Emily Jiang

unread,
Jan 22, 2019, 10:30:21 AM1/22/19
to Eclipse MicroProfile
Good summary, Kevin! I agree most of what you said. I think the following point was still in discussion here. I am not sure myself either.

  • The next MicroProfile Platform release that allows breaking API changes needs to be declared six months in advance to allow for sufficient reaction (development, users, support, vendors, etc).  For example, starting a discussion in July for creating a breaking API Platform release in Oct won't fly (only 4 months).

I think we should discuss this a bit more. Here is the summary I gather:

Agreed on:
1. MicroProfile plans for three releases each year (Feb, June, and Oct).  (Nothing new here, just clarifying.)
2. The MicroProfile 3.0 Platform release in June 2019 will allow breaking API changes from the Components (ie. Metrics 2.0, Config 2.0, and Health Check 2.0).
3. At most 1 MP umbrella spec containing backward incompatible changes should be released per year.
         e.g. MP will just release MP2.2 in Feb, MP 3.0 in June, which contains backward incompatible changes. No more major releases in 2019.
4. The sub specs can freely do a major release with backward incompatible changes at any time. However, this release will not be included by umbrella release targeting for minor spec releases.
        Metrics 2.0 will not be part of MP 2.2 release but it will be included by MP 3.0 in June.
5. The umbrella spec release ignores any spec releases not part of the umbrella release.
       MP does not spec how or whether Metrics 2.0 should work with other specs in MP 2.2.

Still under discussion:
1. Should we fix June release as our opt-in major release automatically? Of course, if no backward incompatible changes are found, we will just do a minor release.
2. Should we keep the option open on which one of the 3 releases be the one with backward incompatible changes? How early can we determine? How to reach consensus on how to organise among the specs to group the backward incompatible changes and target at one umbrella release?

Question: If Feb, June release are minor releases, should we automatically make October as a potential major release?

I think in tonight's discussion, we should discuss the above two options with cons/pros. Also I would like to mention it is important to track backward incompatible changes to warn developers. I will bring it up for further discussion if there is time left for today's call.

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

Ken Finnigan

unread,
Jan 22, 2019, 10:37:43 AM1/22/19
to MicroProfile
On Tue, Jan 22, 2019 at 10:30 AM 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:
Good summary, Kevin! I agree most of what you said. I think the following point was still in discussion here. I am not sure myself either.

  • The next MicroProfile Platform release that allows breaking API changes needs to be declared six months in advance to allow for sufficient reaction (development, users, support, vendors, etc).  For example, starting a discussion in July for creating a breaking API Platform release in Oct won't fly (only 4 months).

I think we should discuss this a bit more. Here is the summary I gather:

Agreed on:
1. MicroProfile plans for three releases each year (Feb, June, and Oct).  (Nothing new here, just clarifying.)
2. The MicroProfile 3.0 Platform release in June 2019 will allow breaking API changes from the Components (ie. Metrics 2.0, Config 2.0, and Health Check 2.0).
3. At most 1 MP umbrella spec containing backward incompatible changes should be released per year.
         e.g. MP will just release MP2.2 in Feb, MP 3.0 in June, which contains backward incompatible changes. No more major releases in 2019.

As mentioned previously, my preference is to say we'd like to minimize how many breaking change releases are done in a single year, but I disagree with saying it's a max of one.

We need to allow for a situation where we've planned a breaking change release for Feb, but around that time there are major advancements or changes that mean we need to update and introduce additional breaking changes that can't make the Feb release. In that situation it makes sense to have a breaking change release for October instead of waiting until the following February.
 
4. The sub specs can freely do a major release with backward incompatible changes at any time. However, this release will not be included by umbrella release targeting for minor spec releases.
        Metrics 2.0 will not be part of MP 2.2 release but it will be included by MP 3.0 in June.
5. The umbrella spec release ignores any spec releases not part of the umbrella release.
       MP does not spec how or whether Metrics 2.0 should work with other specs in MP 2.2.

Still under discussion:
1. Should we fix June release as our opt-in major release automatically? Of course, if no backward incompatible changes are found, we will just do a minor release.
2. Should we keep the option open on which one of the 3 releases be the one with backward incompatible changes? How early can we determine? How to reach consensus on how to organise among the specs to group the backward incompatible changes and target at one umbrella release?

I prefer the flexibility in Kevin's summary, in that it could be any release, but 6 months prior warning needs to be given.
 

Question: If Feb, June release are minor releases, should we automatically make October as a potential major release?

I don't think so, as then we're back to arbitrary major version bumping for no real reason.
 
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.

Ondro Mihályi

unread,
Jan 22, 2019, 10:45:56 AM1/22/19
to MicroProfile
Hi,

Question: If Feb, June release are minor releases, should we automatically make October as a potential major release

I don't think so, as then we're back to arbitrary major version bumping for no real reason.

Emily said "potential" which means that major version would be bumped only if there really are major changes. This is basically what I suggested earlier - to have every June release automatically allow breaking changes if 2 previous releases didn't increase the major version number. If no spec for that release contains breaking changes then we wouldn't bump the version number. I don't see a problem there with arbitrary major version bumps. On the contrary, it would allow breaking changes once a year without thinking about them 6 months in advance.

Ondro

ut 22. 1. 2019 o 16:37 Ken Finnigan <k...@kenfinnigan.me> napísal(a):
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe4rC-W3oZr%3D0fnWSD-22TcvCnNvba-hCF5g5ojs1Q%3DkgQ%40mail.gmail.com.

Emily Jiang

unread,
Jan 22, 2019, 11:07:56 AM1/22/19
to Eclipse MicroProfile
+1 Ondro! I think with what Ondro said and my note earlier, it is feasible as sub specs would have goals to work towards plus one potential ad-doc buffer in bank. I am not sure whether it is realistic for sub specs to know they will need to introduce backward incompatible changes 6 months in advance. Sometimes, I think after lengthy discussion, the best option is to settle on backward incompatible changes.

Anyway, I think at least we know which bits we are not in agreement. We can discuss more later in our MP hangout.

Thanks
Emily

Heiko Rupp

unread,
Jan 22, 2019, 2:12:34 PM1/22/19
to Eclipse MicroProfile
Ondro,

> I think we've agreed that's OK to include a newer version in an MP impl as long as there are no breaking changes. If there are breaking changes, then it obviously wouldn't pass the TCK. Then it's > up to the vendor to do what they want but it's not correct to say that a server provides MP 2.2 if it includes a breaking change from Metrics 2.0. 

I do want TT to still implement Metrics 1.x as default as this in in MP 2.2. This would pass the TCK

I also want (on top) that end-users potentially can use Metrics 2.0 instead to try it out and give us feedback so that we can make smaller adjustments for Metrics 2.1, which would then be includes in MP 3.0 Umbrella
 

Ondro Mihályi

unread,
Jan 22, 2019, 4:07:52 PM1/22/19
to MicroProfile
Hi Heiko,

I also want (on top) that end-users potentially can use Metrics 2.0 instead to try it out and give us feedback so that we can make smaller adjustments for Metrics 2.1, which would then be includes in MP 3.0 Umbrella

I believe this is completely OK.



ut 22. 1. 2019 o 20:12 'Heiko Rupp' via Eclipse MicroProfile <microp...@googlegroups.com> napísal(a):
--
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/uUgU28hJjqA/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.

Alasdair Nottingham

unread,
Jan 23, 2019, 8:47:02 AM1/23/19
to microp...@googlegroups.com
Hi,

I couldn’t make the hangout yesterday so I went to look at the minutes to see the outcome of the discussion, but I don’t see anything there. Does that mean it wasn’t discussed or are the minutes from the discussion being added later?

Thanks
Alasdair

Alasdair Nottingham
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.

Kevin Sutter

unread,
Jan 23, 2019, 9:21:29 AM1/23/19
to Eclipse MicroProfile

Here's the result...

    • DECISION:  Designate the June release as the MP Platform release that will accept breaking changes.  Components can introduce breaking change releases at any time, but can only be included in the platform in the June release.

      • An MP Platform release can include a breaking change at any time if approved by majority vote of the committers

      • The June MP Platform release is not automatically a major (breaking) version change if there are no specs with breaking changes that need to be incorporated.

      • APPROVED

      • Lively discussion:  https://groups.google.com/forum/#!topic/microprofile/uUgU28hJjqA


On Wednesday, January 23, 2019 at 7:47:02 AM UTC-6, Alasdair Nottingham wrote:
Hi,

I couldn’t make the hangout yesterday so I went to look at the minutes to see the outcome of the discussion, but I don’t see anything there. Does that mean it wasn’t discussed or are the minutes from the discussion being added later?

Thanks
Alasdair

Alasdair Nottingham

On Jan 22, 2019, at 4:07 PM, Ondro Mihályi <ondrej....@gmail.com> wrote:

Hi Heiko,

I also want (on top) that end-users potentially can use Metrics 2.0 instead to try it out and give us feedback so that we can make smaller adjustments for Metrics 2.1, which would then be includes in MP 3.0 Umbrella

I believe this is completely OK.



ut 22. 1. 2019 o 20:12 'Heiko Rupp' via Eclipse MicroProfile <microp...@googlegroups.com> napísal(a):
Ondro,

> I think we've agreed that's OK to include a newer version in an MP impl as long as there are no breaking changes. If there are breaking changes, then it obviously wouldn't pass the TCK. Then it's > up to the vendor to do what they want but it's not correct to say that a server provides MP 2.2 if it includes a breaking change from Metrics 2.0. 

I do want TT to still implement Metrics 1.x as default as this in in MP 2.2. This would pass the TCK

I also want (on top) that end-users potentially can use Metrics 2.0 instead to try it out and give us feedback so that we can make smaller adjustments for Metrics 2.1, which would then be includes in MP 3.0 Umbrella
 

--
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/uUgU28hJjqA/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/8a32b73e-6735-4b7c-a52f-1ab2de063e57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Ondro Mihályi

unread,
Jan 23, 2019, 9:43:47 AM1/23/19
to MicroProfile
Hi, I couldn't attend the hangout yesterday but I'm satisfied with the conclusion. Thanks to all that could join yesterday and contributed to the decision.

st 23. 1. 2019 o 15:21 Kevin Sutter <kwsu...@gmail.com> napísal(a):
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/8a32b73e-6735-4b7c-a52f-1ab2de063e57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

--
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/uUgU28hJjqA/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/f3975206-0d24-4bd3-ac57-ff795169a77e%40googlegroups.com.

Emily Jiang

unread,
Jan 23, 2019, 10:39:58 AM1/23/19
to Eclipse MicroProfile
Yep. It was a great discussion. We can always revisit our process if we hit any issues. Truly agile...

Emily

Alasdair Nottingham

unread,
Jan 23, 2019, 11:46:38 AM1/23/19
to microp...@googlegroups.com
Ah, I missed it because of the parent bullet text. 

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.
Reply all
Reply to author
Forward
0 new messages