Metrics 2.1 breaking changes

181 views
Skip to first unread message

Ken Finnigan

unread,
Oct 17, 2019, 11:38:51 AM10/17/19
to MicroProfile
It appears that Metrics 2.1 was released with what can be considered as breaking changes.

In trying to update SmallRye Fault Tolerance to use the latest MP Metrics spec, and also SmallRye Metrics implementation, I encountered some failures in the MP FT TCK related to Metrics.

I raised [1] on MP FT for the issue, but I think it is a bigger problem than just MP FT.

Because MP Metrics changed the Gauge type from:

public interface Gauge<T> extends Metric

to:

public interface Gauge<T extends Number> extends Metric

For MP FT it results in some TCK tests failing with:

java.lang.NoSuchMethodError: org.eclipse.microprofile.metrics.Gauge.getValue()Ljava/lang/Object;


It's highly likely that there's user code that might utilize Gauge in the same way.

So, what options do we have to resolve this?

Ken

Emily Jiang

unread,
Oct 18, 2019, 4:53:33 AM10/18/19
to Eclipse MicroProfile
 This is indeed a backward incompatible change. The version plugin I put in originally should have spotted this. I only found out yesterday that the version plugin was disabled by someone in the metrics repo.

For solving this breaking changes, there are a few options:

1. Relax approach: Document the breaking changes and make an announcement in a MicroProfile 3.1 blog.
2. Extreme approach: Mark Metrics 2.1 and MicroProfile 3.1 as bad, release Metrics 3.0 to be included in June 2020 major release

I think it very much depends on the level of impact. If the impact is small, choose 1. Otherwise, choose 2.

I took a brief look at the change. It impacts on Fault Tolerance. However, from the end user's perspective, the impact is very minimal. I think Option 1 might be ok. Thoughts?

Long term plan: in order to stop this from happening, we must enforce every spec to properly rely on versioning plugin to spot binary incompatible changes. I will drive this forward and discuss more in the next MP call.

Thanks
Emily


Ken Finnigan

unread,
Oct 18, 2019, 7:53:27 AM10/18/19
to MicroProfile
I don't know if 1) is a viable option given that an MP 3.x release shouldn't have breaking changes.

Another option is for Metrics to revert the change and release an MP Metrics 2.1.1 to "fix it" for MP 3.1

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d2d9273a-35ca-4b5a-b8f8-f48c2b8b5085%40googlegroups.com.

Emily Jiang

unread,
Oct 18, 2019, 8:47:38 AM10/18/19
to Eclipse MicroProfile
Strictly speaking "fixing it" is to undo the changes made by Metrics 2.1, which involves changing the APIs. It will not be a micro change, which should be minor change. Metrics 2.2 should be released, which is to level up to Metric 2.0. As MP 3.1 has been released, we have to release another version of umbrella release. I think we need to do another umbrella release, MP 3.2.

Emily

On Friday, October 18, 2019 at 12:53:27 PM UTC+1, Ken Finnigan wrote:
I don't know if 1) is a viable option given that an MP 3.x release shouldn't have breaking changes.

Another option is for Metrics to revert the change and release an MP Metrics 2.1.1 to "fix it" for MP 3.1

On Fri, Oct 18, 2019 at 4:53 AM 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:
 This is indeed a backward incompatible change. The version plugin I put in originally should have spotted this. I only found out yesterday that the version plugin was disabled by someone in the metrics repo.

For solving this breaking changes, there are a few options:

1. Relax approach: Document the breaking changes and make an announcement in a MicroProfile 3.1 blog.
2. Extreme approach: Mark Metrics 2.1 and MicroProfile 3.1 as bad, release Metrics 3.0 to be included in June 2020 major release

I think it very much depends on the level of impact. If the impact is small, choose 1. Otherwise, choose 2.

I took a brief look at the change. It impacts on Fault Tolerance. However, from the end user's perspective, the impact is very minimal. I think Option 1 might be ok. Thoughts?

Long term plan: in order to stop this from happening, we must enforce every spec to properly rely on versioning plugin to spot binary incompatible changes. I will drive this forward and discuss more in the next MP call.

Thanks
Emily


--
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 microp...@googlegroups.com.

John Clingan

unread,
Oct 18, 2019, 9:12:47 AM10/18/19
to MicroProfile
Did any implementation pass the MP 2.1 TCK before releasing it?

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/82d36d86-781b-47d4-ae9b-36b23dd6f562%40googlegroups.com.

Ken Finnigan

unread,
Oct 18, 2019, 9:16:08 AM10/18/19
to MicroProfile
SmallRye did.

The issue is that MP FT breaks because of the change, running anything solely on MP Metrics wouldn't hit the issue

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/587F5895-B851-47ED-BFC3-540AC386F27D%40redhat.com.

John Clingan

unread,
Oct 18, 2019, 10:05:41 AM10/18/19
to microp...@googlegroups.com
OK. Me-thinks we need to adjust processes to catch inter-spec dependency issues beforehand in the future.

Ken Finnigan

unread,
Oct 18, 2019, 10:06:21 AM10/18/19
to MicroProfile
Definitely.

The question is what to do about MP 3.1 now?

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/8E163EBF-897B-4C4D-8D8B-A38727F67734%40redhat.com.

Don Bourne

unread,
Oct 20, 2019, 1:24:29 PM10/20/19
to Eclipse MicroProfile
Hi all,

When this change was initially made it wasn't at first realized that it was a breaking change in MP metrics.  The change had no effect in the smallrye implementation and the thought was that it was just fixing a bug in the spec/api.

For Open Liberty, we also ran the metrics TCK cleanly with this change.  It did eventually occur to us that users of the JSON formatted /metrics interface (not the far more commonly used Prometheus interface) would notice that non-numeric Gauge metrics would no longer appear in the output.  Also, users of the Java API that were using Gauges in a "non-numeric" way could encounter problems -- but we thought that seemed unlikely since people aren't likely to have code with non-numeric Gauges.  

That all said, we do have a break in backward compatibility to address.  

My suggestion is to very quickly put out a new MP Metrics 2.1.1 that reverts to the old Gauge behavior of allowing non-Numeric values.  Describe in the MP Metrics change log that this was to fix an error in MP Metrics 2.1.  That should allow the MP FT TCK to run cleanly again and avoid migration issues from users going from MP Metrics 2.0 to 2.1.  

I realize that this solution isn't perfect but it's soon enough after the MP metrics spec/api/tck release that implementers are still getting this into products and end users are unlikely to have had a chance to create any code reliant on the behavior I'm proposing we revert.  Also, given it's very unlikely people would have created non-numeric gauges, the chance of this causing problems in the field would be small.

Does that seem reasonable?


--
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 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 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 microp...@googlegroups.com.

Emily Jiang

unread,
Oct 20, 2019, 4:22:29 PM10/20/19
to Eclipse MicroProfile
I am not sure whether we can do the release under a micro category as we will be updating APIs. Then, we need to get MP 3.x BOM to include the to-be-released APIs.
Option 1: Release MP Metrics 2.2 and then release MP 3.2.
Option 2: Release MP Metrics 2.1.1 and then release MP 3.1.1.

Either one will fix the problem. I am a bit leaning towards Option 1 as it follows the versioning rules. What other people think?

Thanks
Emily

Werner Keil

unread,
Oct 20, 2019, 6:57:25 PM10/20/19
to Eclipse MicroProfile
Guess that outlines a major difference between Jakarta EE and Microprofile quite well ;-/

--
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 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 microp...@googlegroups.com.

Ondro Mihályi

unread,
Oct 21, 2019, 2:38:18 AM10/21/19
to Eclipse MicroProfile
I'm for bumping the major version of both Metrics and MP umbrella. I saw that most of the time we explain that users don't need to care about the micro versions because they are meant to bring fixes in the TCK and spec doc and are mainly for implementers.

On the other hand, I understand that releasing a new MP major release sooner than planned requires additional effort from us and MP marketing. I'm not sure whether this is worth it.

Maybe release a major version of Metrics and only minor version of MP would be a good compromise?

Ondro

Ladislav Thon

unread,
Oct 21, 2019, 3:19:18 AM10/21/19
to MicroProfile

po 21. 10. 2019 v 8:38 odesílatel Ondro Mihályi <ondrej....@gmail.com> napsal:
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/521c37b2-c9ca-431e-847b-d7ddd1a80b05%40googlegroups.com.

Emily Jiang

unread,
Oct 21, 2019, 6:28:10 AM10/21/19
to Eclipse MicroProfile
Ondro, the quick fix is to revert the change made by Metrics 2.1. This is NOT a major change (changing T extends Number -> T) as the change is a minor change. I think releasing MP metrics 2.2 is clearer and accurate. After we have released MP Metrics 2.2, we need to release MP 3.2 to include it, not suitable for MP 3.1.1 to include a minor release though.

In summary, I think Option 1: Release MP Metrics 2.2 and then release MP 3.2 makes more sense.

Thanks
Emily

Ken Finnigan

unread,
Oct 21, 2019, 8:24:48 AM10/21/19
to MicroProfile
Based on the information provided by Ladislav from SemVer, I would also be in favor of an MP Metrics 2.2 and then an MP 3.1.1 with notifications to users/implementors that MP Metrics 2.1 and MP 3.1 should not be used

On Mon, Oct 21, 2019 at 6:28 AM 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:
I'm for bumping the major version of both Metrics and MP umbrella. I saw that most of the time we explain that users don't need to care about the micro versions because they are meant to bring fixes in the TCK and spec doc and are mainly for implementers.

On the other hand, I understand that releasing a new MP major release sooner than planned requires additional effort from us and MP marketing. I'm not sure whether this is worth it.

Maybe release a major version of Metrics and only minor version of MP would be a good compromise?

Ondro

Ondro, the quick fix is to revert the change made by Metrics 2.1. This is NOT a major change (changing T extends Number -> T) as the change is a minor change. I think releasing MP metrics 2.2 is clearer and accurate. After we have released MP Metrics 2.2, we need to release MP 3.2 to include it, not suitable for MP 3.1.1 to include a minor release though.

In summary, I think Option 1: Release MP Metrics 2.2 and then release MP 3.2 makes more sense.

Thanks
Emily

On Monday, October 21, 2019 at 8:38:18 AM UTC+2, Ondro Mihályi wrote:
I'm for bumping the major version of both Metrics and MP umbrella. I saw that most of the time we explain that users don't need to care about the micro versions because they are meant to bring fixes in the TCK and spec doc and are mainly for implementers.

On the other hand, I understand that releasing a new MP major release sooner than planned requires additional effort from us and MP marketing. I'm not sure whether this is worth it.

Maybe release a major version of Metrics and only minor version of MP would be a good compromise?

Ondro

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/572cdaf7-d6a6-41ea-9d57-e739bddc1e6a%40googlegroups.com.

Jan Martiska

unread,
Oct 21, 2019, 9:38:56 AM10/21/19
to Eclipse MicroProfile
My vote would be for Metrics 2.2 and MP 3.2, it's an API change and so it feels natural to increase the minor release number, but that's just my opinion. MP 3.1.1 would work for me too though.
So, should we proceed with releasing Metrics 2.2 that will be basically just 2.1 with one change reverted?
To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

Emily Jiang

unread,
Oct 21, 2019, 11:36:16 AM10/21/19
to Eclipse MicroProfile
Yes, I am with Jan. We need to do what is right.

We should not release a micro release of MP 3.1.1 to include a new minor change of MP 2.2, which is against the versioning policy. We should release MP 3.2.

In summary, we need to release both MP Metrics 2.2 and MP 3.2.

Thanks
Emily

Emily Jiang

unread,
Oct 21, 2019, 11:48:02 AM10/21/19
to Eclipse MicroProfile
Yes, I am with Jan. We need to do what is right.
We should not release a micro release of MP 3.1.1 to include a new minor change of MP Metrics 2.2, which is against the versioning policy. We should release MP 3.2.

In summary, we need to release both MP Metrics 2.2 and MP 3.2.

p.s. pls ignore my previous note as I missed the word in bold.

Thanks
Emily

John Clingan

unread,
Oct 21, 2019, 11:59:06 AM10/21/19
to MicroProfile
It feels very odd to have a component spec increment a minor version change but the platform spec, which technically also includes a breaking change, to do a patch release. It  becomes a matter of priority, I think - semantic versioning semantics vs MicroProfile “3 releases per year” approach.

I like a 3.2 version number but can still be convinced otherwise.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/89d5ad56-f1b6-4379-881d-145c4a77c34f%40googlegroups.com.

Emily Jiang

unread,
Oct 22, 2019, 3:47:03 AM10/22/19
to Eclipse MicroProfile
I like a 3.2 version number but can still be convinced otherwise.
MP 3.2 is the right call. I don't see any downside for releasing MP 3.2.

I think we need to get this fixed asap with the following 2 actions to take.
1. Release Metrics 2.2
2. Release MP 3.2

Thanks
Emily

Jan Martiska

unread,
Oct 22, 2019, 9:15:38 AM10/22/19
to Eclipse MicroProfile
I submitted a PR with preparations for Metrics 2.2 release https://github.com/eclipse/microprofile-metrics/pull/471 (and created a 2.2.x branch for it)
Once this gets a final ack, the release can happen
Jan

Kevin Sutter

unread,
Oct 22, 2019, 10:50:33 AM10/22/19
to Eclipse MicroProfile
I agree with the Metrics 2.2 update and the MP 3.2 update, but we wait to release MP 3.2 until the regular schedule (Feb 2020).  We basically tell people that MP 3.1 should not be used.  Very soon, we will have Metrics 2.2 that can be used along with the separate Health 2.1.  Then, next year we pick up Metrics 2.2 (along with whatever is ready) for MP 3.2.  I talked this over with Cesar at EclipseCon and he agrees with this approach.  Thoughts?

-- Kevin

Ken Finnigan

unread,
Oct 22, 2019, 10:55:28 AM10/22/19
to MicroProfile
Aren't we being a "bad" open source project by leaving an MP umbrella release in the wild that we know is broken?

Sure, fixing MP Metrics is the most important piece, but if we don't release a new MP umbrella what do implementors implement?

They can implement Health 2.1 and Metrics 2.2, but that's not an MP umbrella release combination. So what do they say they're compatible with?



To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/8735ba96-98c8-4cd4-bde2-fb4de5b3bc8c%40googlegroups.com.

John Clingan

unread,
Oct 22, 2019, 3:14:00 PM10/22/19
to Eclipse MicroProfile
I'm rethinking this. There are currently no implementations of MicroProfile 3.1 out there (that I know of), so the change will not break anyone's app. Also, we are reverting back to a working (existing) situation. Last, it feels odd to go from MP 3.1 -> 3.2 -> 3.3 instead of MP 3.1 -> 3.2 just to back out and then re-apply a feature. 

So, I think I prefer 3.1.1 (and probably Metrics 2.1.1). I think this will be a *lot* more clear to users that what we are doing is fixing an issue rather than adding features.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

Emily Jiang

unread,
Oct 22, 2019, 3:21:01 PM10/22/19
to Microprofile
We are using semantic versioning, not  use arbitrary numbers to cover any mistakes. 
With this, I think releasing micro versions is not accurate.
Emily 


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/BO00mGLw83c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4b3449ea-0476-48ee-b228-06d116d687c9%40googlegroups.com.

Werner Keil

unread,
Oct 22, 2019, 3:41:18 PM10/22/19
to Eclipse MicroProfile
I think that is better.
I know some Open Source project, I think the Linux kernel or so had a history of "stable" and "less stable" releases by odd or even digits, but unless Microprofile wants to establish something like that e.g. 3.1 "bad", 3.2 "good" etc. A fairly quick fix might be better.
The JDK does it in certain intervals, Apple seemingly had to fix their latest iOS once a week, so I see nothing wrong with that.

Werner

Rudy De Busscher

unread,
Oct 22, 2019, 3:55:47 PM10/22/19
to Eclipse MicroProfile
We at Payara will release MP 3.1 implementation in a month. And we don't like to wait to have a correct umbrella version until February.

So we either ship it as MP 3.1 with Metrics 2.2 (which is not entirely correct to say) or we very much like to have MP 3.2.

I don't think it is a shame to admit that you have made a 'mistake' and explain why we are releasing another version.

It is much better than just have only MP3.1 for another 4 months as the last version but we give the message that users can't use it. (Well you technical can use it can but according to semantic versioning there is a problem with the release)

Rudy

Kevin Sutter

unread,
Oct 23, 2019, 1:52:35 AM10/23/19
to Eclipse MicroProfile
Thanks, Rudy.  Good input.

We (Liberty) had plans to ship MP 3.1 very soon, but we now have it on hold until we figure out the Community's direction.

Based on my understanding of the Metrics issue, I think it makes sense to produce an updated Metrics 2.2 (not 2.1.1).  I believe we are changing an API and that doesn't belong in a patch/service release level.  We need to update the minor version, thus 2.2 is the correct direction.

I was also under the impression that we could somehow mark the MP 3.1 release as "bad" or "don't use" or something like that.  I know we couldn't remove it completely, but I thought there was some way to indicate that this shouldn't be used.  If that's not possible, then maybe our only recourse is to quickly stage an MP 3.2 release and get that out the door.  When I talked with Emily about this last night, she summed it up by saying at least we would be sticking to our delivery schedule of "three good releases per year".  :-)

-- Kevin

Ondro Mihályi

unread,
Oct 23, 2019, 5:39:26 AM10/23/19
to Eclipse MicroProfile
I like the schedule of 3 "good" releases per year :)

As Rudy said, Payara plans to implement MP 3.1 before the end of year. Having to wait until next year for MP 3.2 puts us in a comicated position, especially since we don't suport MP 3.0 now. There may be be other implementers like Helidon in a similar situation.

Even without this situation at Payara, I believe we should be fast in fixing our own mistakes and release Metrics 2.2 and MP 3.2 or 3.1.1 ASAP and then release the next MP version in Feb next year as usual.

Ondro

Emily Jiang

unread,
Oct 23, 2019, 3:12:25 PM10/23/19
to Eclipse MicroProfile
With the discussion, I think we have finally reached the agreement to release Metrics 2.2 and MP 3.2 asap. Let's working on the releases now...
Thanks
Emily

John Clingan

unread,
Oct 23, 2019, 3:31:03 PM10/23/19
to Eclipse MicroProfile
OK. I'll start the work on MicroProfile 3.2 release. Emily, don't forget to create a CQ for Metrics 2.2.

John Clingan

unread,
Oct 23, 2019, 3:44:35 PM10/23/19
to Eclipse MicroProfile
Also, please make sure the version is 2.2 and not 2.2.0. We need to break away from including the patch ".0" release number for Metrics.
Thanks!


On Wednesday, October 23, 2019 at 12:12:25 PM UTC-7, Emily Jiang wrote:

John Clingan

unread,
Oct 24, 2019, 9:11:08 AM10/24/19
to Eclipse MicroProfile


On Wednesday, October 23, 2019 at 12:12:25 PM UTC-7, Emily Jiang wrote:

John Clingan

unread,
Oct 24, 2019, 3:52:50 PM10/24/19
to Eclipse MicroProfile
Emily, I need to define a 3.2 release datee. Can you estimate when 2.2 will be final with a completed build? I am thinking Oct 31st or Nov 1st.


On Wednesday, October 23, 2019 at 12:12:25 PM UTC-7, Emily Jiang wrote:

Emily Jiang

unread,
Oct 24, 2019, 4:01:02 PM10/24/19
to Microprofile
Hi John,
I believe Jan is working on it! I enabled the version plugin and Jan reverted the API changes. I would say early next week the final should be available. Jan, please go ahead to do Metrics 2.2-RC1 ASAP.
Thanks Emily 


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

Jan Martiska

unread,
Oct 25, 2019, 7:04:48 AM10/25/19
to Eclipse MicroProfile
2.2-RC1 is now released in Maven Central.
I'd like guys from IBM (Don) to give it a test round, after that we can turn it into Final. I will be offline on Monday, so if it's necessary to do that on Monday, someone else will have to do it.
Jan

On Thursday, October 24, 2019 at 10:01:02 PM UTC+2, Emily Jiang wrote:
Hi John,
I believe Jan is working on it! I enabled the version plugin and Jan reverted the API changes. I would say early next week the fyinal should be available. Jan, please go ahead to do Metrics 2.2-RC1 ASAP.
Thanks Emily 


On Oct 24, 2019 at 8:52 pm, <John Clingan> wrote:

Emily, I need to define a 3.2 release datee. Can you estimate when 2.2 will be final with a completed build? I am thinking Oct 31st or Nov 1st.
https://projects.eclipse.org/projects/technology.microprofile/governance

On Wednesday, October 23, 2019 at 12:12:25 PM UTC-7, Emily Jiang wrote:
With the discussion, I think we have finally reached the agreement to release Metrics 2.2 and MP 3.2 asap. Let's working on the releases now...
Thanks
Emily

On Wednesday, October 23, 2019 at 11:39:26 AM UTC+2, Ondro Mihályi wrote:
I like the schedule of 3 "good" releases per year :)

As Rudy said, Payara plans to implement MP 3.1 before the end of year. Having to wait until next year for MP 3.2 puts us in a comicated position, especially since we don't suport MP 3.0 now. There may be be other implementers like Helidon in a similar situation.

Even without this situation at Payara, I believe we should be fast in fixing our own mistakes and release Metrics 2.2 and MP 3.2 or 3.1.1 ASAP and then release the next MP version in Feb next year as usual.

Ondro

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

Don Bourne

unread,
Oct 25, 2019, 8:41:52 AM10/25/19
to Eclipse MicroProfile
We're giving 2.2-RC1 a try -- should have results a bit later today.

Don Bourne

unread,
Oct 25, 2019, 9:00:27 AM10/25/19
to Eclipse MicroProfile
@John, I've created the Metrics 2.2 release at https://projects.eclipse.org/projects/technology.microprofile/releases

Emily Jiang

unread,
Oct 25, 2019, 10:24:41 AM10/25/19
to Eclipse MicroProfile


OK. I'll start the work on MicroProfile 3.2 release. Emily, don't forget to create a CQ for Metrics 2.2.
John, which CQ do you mean? By the way, Eclipse Foundation has better CQ management now. I will share that on a separate thread.
Thanks
Emily
Reply all
Reply to author
Forward
0 new messages