Thanks Owen. I am going to re-cut the branch for 1.9.0 and request
community to do the sanity check for the new branch.
On Fri, Mar 22, 2019 at 4:24 PM Owen Nichols wrote:
> @Sai, this discussion has received no objections and enough +1’s to
> proceed with re-cutting the release 1.9.0 branch.
>
@Sai, this discussion has received no objections and enough +1’s to proceed
with re-cutting the release 1.9.0 branch.
Looking at the pipeline this week, it has been pretty green since SHA
ec5a24b78c51b6a29b8bf656f91004d09510d244. I recommend re-cutting the 1.9.0
release branch from this SHA.
I'm fine releasing with just the service loader API for micrometer.
I'd just like the folks working on these new public APIs agree that they
are ok with these APIs getting released to end users and put to use in the
state they are right now.
-Dan
On Wed, Mar 20, 2019 at 12:43 PM Dale Emery wrot
I can help.
> On Mar 20, 2019, at 5:08 PM, Sai Boorlagadda
> wrote:
>
> I would like to resolve the issue around NOTICE and LICENSE files related
> to new/removed dependencies on develop, which I have a PR[1] open and would
> need some guidance.
> There is some feedback provided by Dick earlier
I would like to resolve the issue around NOTICE and LICENSE files related
to new/removed dependencies on develop, which I have a PR[1] open and would
need some guidance.
There is some feedback provided by Dick earlier this week and I would like
to see if I can get some help.
[1] https://github.com
> On Mar 20, 2019, at 11:25 AM, Alexander Murmann wrote:
>
> Dale, is there any downside to making these changes in 1.10 other than
> plainly having them later?
I don’t think so, but I’d want to hear Dan’s opinion on that, given that his
approval of our PR was contingent on our promise to do it
Dale, is there any downside to making these changes in 1.10 other than
plainly having them later?
On Wed, Mar 20, 2019 at 11:15 AM Dave Barnes wrote:
> geode-native is ready to into the 1.9 release candidate build.
>
> On Wed, Mar 20, 2019 at 10:42 AM Dave Barnes wrote:
>
> > The geode-native P
geode-native is ready to into the 1.9 release candidate build.
On Wed, Mar 20, 2019 at 10:42 AM Dave Barnes wrote:
> The geode-native PR will be ready to check in momentarily. Just waiting
> for Travis to do its diligence.
>
> On Wed, Mar 20, 2019 at 9:47 AM Alexander Murmann
> wrote:
>
>> Dale
Hi Alexander,
> On Mar 20, 2019, at 9:47 AM, Alexander Murmann wrote:
>
> Dale, do I understand correctly that the only concern around the Micrometer
> work right now it that it's not useful yet, however it's not harmful either?
It’s useful, but somewhat less usable than we want it to be. Curr
The geode-native PR will be ready to check in momentarily. Just waiting for
Travis to do its diligence.
On Wed, Mar 20, 2019 at 9:47 AM Alexander Murmann
wrote:
> Dale, do I understand correctly that the only concern around the Micrometer
> work right now it that it's not useful yet, however it'
Dale, do I understand correctly that the only concern around the Micrometer
work right now it that it's not useful yet, however it's not harmful either?
Dave, is it correct that if that PR doesn't make it into the newly cut
branch, we'd be shipping with a older version of geode-native? What are th
The Geode 1.9.0 release includes a source-only release of the geode-native
repo. There's a pull-request in process to update version numbers and the
doc build environment in that repo; should be ready to merge tomorrow
morning.
On Tue, Mar 19, 2019 at 5:20 PM Dale Emery wrote:
> The Micrometer A
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..
Manageability just yesterday moved all work-in-progress behind a feature flag;
yes, we are comfortable releasing in the current state.
> On Mar 19, 2019, at 3:29 PM, Dan Smith wrote:
>
> Is the geode-managability sub-project and the new micrometer API in a place
> where we can cut a release
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
+1. We want to ship with confidence and we have more trust in develop right
now.
On Tue, Mar 19, 2019 at 2:11 PM Dick Cavender 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
> wro
+1 to re-cut.
-Anil.
On Tue, Mar 19, 2019 at 2:11 PM Dick Cavender 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
> wrote:
>
> > If we recut the release branch we need to update
+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
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:
> > >
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 shi
> 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 c
20 matches
Mail list logo
