The Micrometer API is in, and marked as experimental. But we have not yet updated CacheFactory to allow injecting a meter registry (or metrics publishing service) there. So currently the only way to publish is to add metrics publishing service via the ServiceLoader mechanism.
— Dale Emery dem...@pivotal.io > On Mar 19, 2019, at 3:29 PM, Dan Smith <dsm...@pivotal.io> wrote: > > Is the geode-managability sub-project and the new micrometer API in a place > where we can cut a release branch? I know a bunch of changes have gone in > since the release branch, are we comfortable releasing these new > experimental features as they are right now? > > -Dan > > On Tue, Mar 19, 2019 at 2:38 PM Dick Cavender <di...@apache.org> wrote: > >> +1 to re-cutting the 1.9 release branch off a more stable develop sha >> within the last couple days. >> >> On Tue, Mar 19, 2019 at 1:14 PM Bruce Schuchardt <bschucha...@pivotal.io> >> wrote: >> >>> If we recut the release branch we need to update JIRA tickets marked >>> fixed in 1.10 >>> >>> On 3/19/19 12:48 PM, Sai Boorlagadda wrote: >>>>> It was known at the time that develop was not as stable as desired, >>>> so we planned to cherry-pick fixes from develop until the release >>>> branch was stable enough to ship. >>>> I want to clarify that we decided to cut the release branch not that >>>> develop was not stable. But really that it is desirable to cut the >>>> branch sooner to avoid any regression risk that can be introduced by >>>> on-going work on develop. >>>> >>>> Nevertheless looks like develop is more stable than release branch due >>>> to some test fixes that were not cherry-picked into the release branch. >>>> I think its a good idea to re-cut the branch as our current position >>>> to stabilize release branch before releasing. >>>> >>>> +1 to re-cut. >>>> >>>> Sai >>>> >>>> On Tue, Mar 19, 2019 at 12:19 PM Owen Nichols <onich...@pivotal.io >>>> <mailto:onich...@pivotal.io>> wrote: >>>> >>>> The Geode 1.9.0 release branch was originally cut 4 weeks ago on >>>> Feb 19. It was known at the time that develop was not as stable >>>> as desired, so we planned to cherry-pick fixes from develop until >>>> the release branch was stable enough to ship. While this is a >>>> good strategy when starting from a fairly good baseline, it seems >>>> in this case it has only added complexity without leading to >>>> stability. >>>> >>>> Looking at the pipelines over the last week (see attached >>>> metrics), it appears we have been far more successful at >>>> stabilizing /develop/ than /release/1.9.0/. Rather than trying to >>>> cherry-pick more and more fixes to the release branch, I propose >>>> we RE-CUT the 1.9.0 release branch later this week in order to >>>> start from a much more stable baseline. >>>> >>>> -Owen >>>> >>>> >>>> >>> >>
