Re: [DISCUSS] Time to cut Geode 1.10.0?
I believe it's realistic to assume that On Mon, Jul 22, 2019, 3:58 PM Alexander Murmann wrote: > Jinmei, > > Do you think it's realistic to add the property this week and still cut the > branch at the end of this week? > > On Mon, Jul 22, 2019 at 3:38 PM Jinmei Liao wrote: > > > Work is still being planned to move the cluster management rest service > > under an experimental version flag and use a geode property to turn it > > on/off. I would say we are ready to cut the geode 1.10.0 after that work > is > > complete. > > > > On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann > > wrote: > > > > > Hi everyone! > > > > > > We released Geode 1.9.0 on April 25th. That's about 3 months ago. End > of > > > last year we discussed releasing quarterly. In the past we've had > about a > > > month between cutting a release branch and actually shipping our new > > minor. > > > This means we are already behind our target release cadence. > > > > > > What are your thoughts on cutting a 1.10.0 release branch this week? > > > > > > Would anyone like to volunteer to be the release manager for geode > > 1.10.0? > > > > > > Thank you all! > > > > > > > > > -- > > Cheers > > > > Jinmei > > >
Re: [DISCUSS] Time to cut Geode 1.10.0?
Udo, do you mind explaining how the RFC process comes into this? Are you suggesting that we should wait if an RFC had a target release attached? On Mon, Jul 22, 2019 at 4:47 PM Udo Kohlmeyer wrote: > I don't think we need to wait for this, as there has been no RFC process > followed. > > --Udo > > On 7/22/19 3:38 PM, Jinmei Liao wrote: > > Work is still being planned to move the cluster management rest service > > under an experimental version flag and use a geode property to turn it > > on/off. I would say we are ready to cut the geode 1.10.0 after that work > is > > complete. > > > > On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann > > wrote: > > > >> Hi everyone! > >> > >> We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of > >> last year we discussed releasing quarterly. In the past we've had about > a > >> month between cutting a release branch and actually shipping our new > minor. > >> This means we are already behind our target release cadence. > >> > >> What are your thoughts on cutting a 1.10.0 release branch this week? > >> > >> Would anyone like to volunteer to be the release manager for geode > 1.10.0? > >> > >> Thank you all! > >> > > >
Re: [DISCUSS] Time to cut Geode 1.10.0?
I don't think we need to wait for this, as there has been no RFC process followed. --Udo On 7/22/19 3:38 PM, Jinmei Liao wrote: Work is still being planned to move the cluster management rest service under an experimental version flag and use a geode property to turn it on/off. I would say we are ready to cut the geode 1.10.0 after that work is complete. On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann wrote: Hi everyone! We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of last year we discussed releasing quarterly. In the past we've had about a month between cutting a release branch and actually shipping our new minor. This means we are already behind our target release cadence. What are your thoughts on cutting a 1.10.0 release branch this week? Would anyone like to volunteer to be the release manager for geode 1.10.0? Thank you all!
Re: [DISCUSS] Time to cut Geode 1.10.0?
Jinmei, Do you think it's realistic to add the property this week and still cut the branch at the end of this week? On Mon, Jul 22, 2019 at 3:38 PM Jinmei Liao wrote: > Work is still being planned to move the cluster management rest service > under an experimental version flag and use a geode property to turn it > on/off. I would say we are ready to cut the geode 1.10.0 after that work is > complete. > > On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann > wrote: > > > Hi everyone! > > > > We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of > > last year we discussed releasing quarterly. In the past we've had about a > > month between cutting a release branch and actually shipping our new > minor. > > This means we are already behind our target release cadence. > > > > What are your thoughts on cutting a 1.10.0 release branch this week? > > > > Would anyone like to volunteer to be the release manager for geode > 1.10.0? > > > > Thank you all! > > > > > -- > Cheers > > Jinmei >
Re: [DISCUSS] Time to cut Geode 1.10.0?
Work is still being planned to move the cluster management rest service under an experimental version flag and use a geode property to turn it on/off. I would say we are ready to cut the geode 1.10.0 after that work is complete. On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann wrote: > Hi everyone! > > We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of > last year we discussed releasing quarterly. In the past we've had about a > month between cutting a release branch and actually shipping our new minor. > This means we are already behind our target release cadence. > > What are your thoughts on cutting a 1.10.0 release branch this week? > > Would anyone like to volunteer to be the release manager for geode 1.10.0? > > Thank you all! > -- Cheers Jinmei
[DISCUSS] Time to cut Geode 1.10.0?
Hi everyone! We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of last year we discussed releasing quarterly. In the past we've had about a month between cutting a release branch and actually shipping our new minor. This means we are already behind our target release cadence. What are your thoughts on cutting a 1.10.0 release branch this week? Would anyone like to volunteer to be the release manager for geode 1.10.0? Thank you all!
Hostname validation
Hi, When SSL is enabled and ssl-endpoint-identification-enabled flag is set to true, hostname validation is performed while establishing a connection. This includes checking the hostname and IP address in the certificate. In past releases, if hostname validation was disabled, a warning log message would pop up saying hostname validation will become mandatory in future Geode releases. This message has been removed in recent releases, but we would still like to check whether there is a plan to mandate hostname validation. The reasons for asking are the implementation problems in cloud native applications with hostname and IP validation. The IP address can change after each restart, and it would be extremely cumbersome maintaining that in the certificates. And in general, sticking to specific IP addresses doesn’t go in line with cloud native principles.
