Re: [DISCUSS] Geode 1.14
> On Jan 4, 2021, at 3:42 PM, Owen Nichols wrote: > > How to tell whether develop is stable? Same way we tell if a release branch is stable. Listen, cutting a release branch from the develop branch shouldn’t result in weeks worth of stabilization of the release branch. That is a smell that we have bad things going into develop. If there are bad things in develop then we are introducing new things to develop on top of bad things, which will just end up being more bad things. It isn’t cut or dry. I am not saying release from develop on an arbitrary day. I am saying we know develop isn’t stable. We know a release branch will take weeks to repair. Lets turn that around, lets make develop stable so a release branch takes days to release, not weeks. Yes there will be issues found on a release branch that have to be fixed but that should be an exception, not the norm. -Jake
Re: [DISCUSS] Geode 1.14
A JIRA dashboard for 1.14.0 might help. Do we currently have one? I am not sure whether there is some JIRA label introduced for the release of 1.14.0. A quick search of open JIRA that affects 1.14.0 returns 29 tickets. Jianxia On Mon, Jan 4, 2021 at 3:43 PM Owen Nichols wrote: > How to tell whether develop is stable? > > From: Jacob Barrett > Date: Monday, January 4, 2021 at 8:59 AM > To: dev@geode.apache.org > Subject: Re: [DISCUSS] Geode 1.14 > Keep develop stable, cut when we want to release. If develop isn’t stable > we don’t cut until it is. There is no reason we can’t keep develop stable. > If develop is stable then there is no reason we can’t release when we want > to, whether that is a date or after a feature. > > -Jake > > > > On Jan 4, 2021, at 7:22 AM, Anilkumar Gingade > wrote: > > > > My recommendation will be: > > - Identify, Prioritize, Merge 1.14 related work > > - Stabilize. Cut the branch and Stabilize again (to test any new changes > added during first stabilize period) > > > > -Anil. > > > > > > On 12/18/20, 2:26 PM, "Mark Hanson" wrote: > > > >I support the cut on a predetermined date. But I will be ok with the > Stabilize first approach, because I think that having a stable build is a > prerequisite for any time based model. But like all things, this is a smell > that we have to do this... The other thing is that specifying a date or a > window of time in my opinion is crucial to ensuring freshly baked features > are not merged until we cut the release. The window need not be very long a > day or two as an example. With the volume of defects that we need to > assess/fix maintaining control of develop seems important. So I would > propose that we give notice of when we are looking to cut the branch (once > we have made adequate determinations for the defects). > > > >Thanks, > >Mark > > > >On 12/18/20, 12:09 PM, "Owen Nichols" wrote: > > > >To summarize this thread so far: > >@Robert and @Jens seem to favor “cut then stabilize” > >@Alexander and @John seem to favor “stabilize then cut” > >No one seems to favor “cut on a predetermined date” (at least for > 1.14) > > > >@John also made a creative suggestion that maybe 1.14 doesn’t > have to be cut from latest develop…what if we cut it from support/1.13 and > then backport just the redis changes (in parallel with continuing to > stabilize what’s currently on develop into a 1.15 release). > > > >For now let’s try to proceed on the “stabilize then cut” plan. > All committers, please hold off on merging big refactorings or other > high-risk changes to develop until after the branch is cut. Let’s regroup > next month and try to clarify exactly which GEODE Jira tickets we need to > focus on to make sure 1.14 is our best release. > > > >From: Owen Nichols > >Date: Tuesday, December 1, 2020 at 12:26 PM > >To: dev@geode.apache.org > >Subject: Re: [DISCUSS] Geode 1.14 > >If someone wants to propose a list of must-fix Jira tickets > before we can cut the branch, I see that as a shift from a time-based to > feature-based branch-cut strategy. Might be fun to try? > > > >Given the distributed nature of the Geode community, picking a > date and sticking to it allows decentralized decision-making (each > contributor can plan on their own what they can finish and/or how they can > help get develop as stable as possible by that date). > > > >To answer your question: the current state of develop feels > “pretty good” to me. Knowing that only critical fixes will be allowed onto > the branch once cut, the question is really about features. It sounds like > there is redis work we’d like to ship. Anything else nearly-done we should > considering waiting on? > > > >From: Alexander Murmann > >Date: Monday, November 30, 2020 at 11:57 AM > >To: dev@geode.apache.org > >Subject: Re: [DISCUSS] Geode 1.14 > >Hi all, > > > >Thanks, Owen for reminding us all of this topic! > > > >I wonder how we feel about the state of develop right now. If we > cut 1.14 right now, it will make it easier to stabilize and ship it. > However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to > have an all-hands effort to address as much as possible on develop and then > cut 1.14. If we shift all attention to 1.14, develop will likely never get > better. I'd love to get closer to an always shippable develop branch. That > should vastly reduce future release pain and make everyday development > better as well. > > > >Thoughts? > > > >From: Jens Deppe > >Sent: Wednesday, November 25, 2020 20:11 > >To: dev@geode.apache.org > >Subject: Re: [DISCUSS] Geode 1.14 > > > >Hi Owen, > > > >Thanks for starting this conversation and especially for > volunteering as Release Manager! > > > >
Re: [DISCUSS] Geode 1.14
How to tell whether develop is stable? From: Jacob Barrett Date: Monday, January 4, 2021 at 8:59 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 Keep develop stable, cut when we want to release. If develop isn’t stable we don’t cut until it is. There is no reason we can’t keep develop stable. If develop is stable then there is no reason we can’t release when we want to, whether that is a date or after a feature. -Jake > On Jan 4, 2021, at 7:22 AM, Anilkumar Gingade wrote: > > My recommendation will be: > - Identify, Prioritize, Merge 1.14 related work > - Stabilize. Cut the branch and Stabilize again (to test any new changes > added during first stabilize period) > > -Anil. > > > On 12/18/20, 2:26 PM, "Mark Hanson" wrote: > >I support the cut on a predetermined date. But I will be ok with the > Stabilize first approach, because I think that having a stable build is a > prerequisite for any time based model. But like all things, this is a smell > that we have to do this... The other thing is that specifying a date or a > window of time in my opinion is crucial to ensuring freshly baked features > are not merged until we cut the release. The window need not be very long a > day or two as an example. With the volume of defects that we need to > assess/fix maintaining control of develop seems important. So I would > propose that we give notice of when we are looking to cut the branch (once we > have made adequate determinations for the defects). > >Thanks, >Mark > >On 12/18/20, 12:09 PM, "Owen Nichols" wrote: > >To summarize this thread so far: >@Robert and @Jens seem to favor “cut then stabilize” >@Alexander and @John seem to favor “stabilize then cut” >No one seems to favor “cut on a predetermined date” (at least for 1.14) > >@John also made a creative suggestion that maybe 1.14 doesn’t have to > be cut from latest develop…what if we cut it from support/1.13 and then > backport just the redis changes (in parallel with continuing to stabilize > what’s currently on develop into a 1.15 release). > >For now let’s try to proceed on the “stabilize then cut” plan. All > committers, please hold off on merging big refactorings or other high-risk > changes to develop until after the branch is cut. Let’s regroup next month > and try to clarify exactly which GEODE Jira tickets we need to focus on to > make sure 1.14 is our best release. > >From: Owen Nichols >Date: Tuesday, December 1, 2020 at 12:26 PM >To: dev@geode.apache.org >Subject: Re: [DISCUSS] Geode 1.14 >If someone wants to propose a list of must-fix Jira tickets before we > can cut the branch, I see that as a shift from a time-based to feature-based > branch-cut strategy. Might be fun to try? > >Given the distributed nature of the Geode community, picking a date > and sticking to it allows decentralized decision-making (each contributor can > plan on their own what they can finish and/or how they can help get develop > as stable as possible by that date). > >To answer your question: the current state of develop feels “pretty > good” to me. Knowing that only critical fixes will be allowed onto the > branch once cut, the question is really about features. It sounds like there > is redis work we’d like to ship. Anything else nearly-done we should > considering waiting on? > >From: Alexander Murmann >Date: Monday, November 30, 2020 at 11:57 AM >To: dev@geode.apache.org >Subject: Re: [DISCUSS] Geode 1.14 >Hi all, > >Thanks, Owen for reminding us all of this topic! > >I wonder how we feel about the state of develop right now. If we cut > 1.14 right now, it will make it easier to stabilize and ship it. However, I > see 21 open JIRA tickets affecting 1.14.0. It might be better to have an > all-hands effort to address as much as possible on develop and then cut 1.14. > If we shift all attention to 1.14, develop will likely never get better. I'd > love to get closer to an always shippable develop branch. That should vastly > reduce future release pain and make everyday development better as well. > >Thoughts? > >From: Jens Deppe >Sent: Wednesday, November 25, 2020 20:11 >To: dev@geode.apache.org >Subject: Re: [DISCUSS] Geode 1.14 > >Hi Owen, > >Thanks for starting this conversation and especially for volunteering > as Release Manager! > >Since we're already a couple of quarters 'behind', in terms of > releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means > we'll have 9 months of changes to stabilize. How long might that take to > finally get shipped? (rhetorical). > >--Jens > >On 11/25/20, 6:05 PM, "Owen Nichols" wrote: > >The trigger in @Alexander’s July 28 proposal t
RE: State of https://github.com/apache/geode-dotnet-core-client
The dotnet-core-client repo is at best a placeholder at present, and is not suitable for any kind of use. It requires a special build of geode-native that contains c-style exported API functions, that is only available on a branch on one of my forks IIRC. It exists under the apache project because we desperately needed to get it under revision control to preserve WIP, and starting under apache avoided a potentially difficult future migration. I can prioritize a PR to scrub proprietary names, but please understand we've been trying to get back to this repo for several _months_ now and been swamped with patch releases and customer bugs/support requests, so I don't wish to set expectations very high. As far as tests for the code, yes they exist and cover the "supported" API thus far, which is not a lot. If everything is set up correctly, however, creating a cache factory, cache, pool, region, and put/get of string key/value pairs works. Thanks, Blake -Original Message- From: John Hutchison Sent: Tuesday, December 29, 2020 11:24 AM To: dev@geode.apache.org Subject: Re: State of https://github.com/apache/geode-dotnet-core-client Is there some kind linting that we could put into spotless (or a linting tool that's run before spotless) to prevent this kind of thing (check against known proprietary names and derivatives before being allowed through ci)? From: Jacob Barrett Date: Tuesday, December 29, 2020 at 1:08 PM To: dev@geode.apache.org Subject: Re: State of https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-dotnet-core-client&data=04%7C01%7Cbblake%40vmware.com%7C35d72397c8b5436f342808d8ac2f562e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63744804574411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=alFiaIqSZZBmtPVHNYIzfHJBqJT6rthLXIPccs%2BwTGU%3D&reserved=0 Wow, that's pretty bad that we put proprietary references into this repo from the start. If you have the bandwidth a cleanup PR would be appreciated. I can't speak to the functionality but I would hope there are unit and integration tests that assert the supported behavior. -Jake > On Dec 21, 2020, at 4:48 PM, Michael Oleske wrote: > > Hi Geode Dev Friends! > > I'm starting a personal little side project and was thinking of using Geode > as my backend (no real reason, certainly doesn't need the capabilities of > Geode, but thought it'd be fun.) I'm writing my application in .NET 5 (which > is core based) and was going to try and use > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-dotnet-core-client&data=04%7C01%7Cbblake%40vmware.com%7C35d72397c8b5436f342808d8ac2f562e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63744804574411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=alFiaIqSZZBmtPVHNYIzfHJBqJT6rthLXIPccs%2BwTGU%3D&reserved=0 > > I see no one has really made any changes to it for a while, and that it seems > to have some proprietary references in it. Is it in a usable state for > simple puts/gets? > > -michael
Re: [DISCUSS] Geode 1.14
My opinion: (1) List out must fix bugs for 1.4 (I don’t think there’s any, but it’s good to review) (2) cut the 1.4 release branch and start the stabilization period asap. Gester From: Anilkumar Gingade Date: Monday, January 4, 2021 at 7:23 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 My recommendation will be: - Identify, Prioritize, Merge 1.14 related work - Stabilize. Cut the branch and Stabilize again (to test any new changes added during first stabilize period) -Anil. On 12/18/20, 2:26 PM, "Mark Hanson" wrote: I support the cut on a predetermined date. But I will be ok with the Stabilize first approach, because I think that having a stable build is a prerequisite for any time based model. But like all things, this is a smell that we have to do this... The other thing is that specifying a date or a window of time in my opinion is crucial to ensuring freshly baked features are not merged until we cut the release. The window need not be very long a day or two as an example. With the volume of defects that we need to assess/fix maintaining control of develop seems important. So I would propose that we give notice of when we are looking to cut the branch (once we have made adequate determinations for the defects). Thanks, Mark On 12/18/20, 12:09 PM, "Owen Nichols" wrote: To summarize this thread so far: @Robert and @Jens seem to favor “cut then stabilize” @Alexander and @John seem to favor “stabilize then cut” No one seems to favor “cut on a predetermined date” (at least for 1.14) @John also made a creative suggestion that maybe 1.14 doesn’t have to be cut from latest develop…what if we cut it from support/1.13 and then backport just the redis changes (in parallel with continuing to stabilize what’s currently on develop into a 1.15 release). For now let’s try to proceed on the “stabilize then cut” plan. All committers, please hold off on merging big refactorings or other high-risk changes to develop until after the branch is cut. Let’s regroup next month and try to clarify exactly which GEODE Jira tickets we need to focus on to make sure 1.14 is our best release. From: Owen Nichols Date: Tuesday, December 1, 2020 at 12:26 PM To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 If someone wants to propose a list of must-fix Jira tickets before we can cut the branch, I see that as a shift from a time-based to feature-based branch-cut strategy. Might be fun to try? Given the distributed nature of the Geode community, picking a date and sticking to it allows decentralized decision-making (each contributor can plan on their own what they can finish and/or how they can help get develop as stable as possible by that date). To answer your question: the current state of develop feels “pretty good” to me. Knowing that only critical fixes will be allowed onto the branch once cut, the question is really about features. It sounds like there is redis work we’d like to ship. Anything else nearly-done we should considering waiting on? From: Alexander Murmann Date: Monday, November 30, 2020 at 11:57 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 Hi all, Thanks, Owen for reminding us all of this topic! I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well. Thoughts? From: Jens Deppe Sent: Wednesday, November 25, 2020 20:11 To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 Hi Owen, Thanks for starting this conversation and especially for volunteering as Release Manager! Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical). --Jens On 11/25/20, 6:05 PM, "Owen Nichols" wrote: The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13). It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager. Below are all release dates since Geode adopted a time-based release cadence. Minor releases: 1.13 branch cut May 4 2020, 1.13.0 shi
Re: [DISCUSS] Geode 1.14
Keep develop stable, cut when we want to release. If develop isn’t stable we don’t cut until it is. There is no reason we can’t keep develop stable. If develop is stable then there is no reason we can’t release when we want to, whether that is a date or after a feature. -Jake > On Jan 4, 2021, at 7:22 AM, Anilkumar Gingade wrote: > > My recommendation will be: > - Identify, Prioritize, Merge 1.14 related work > - Stabilize. Cut the branch and Stabilize again (to test any new changes > added during first stabilize period) > > -Anil. > > > On 12/18/20, 2:26 PM, "Mark Hanson" wrote: > >I support the cut on a predetermined date. But I will be ok with the > Stabilize first approach, because I think that having a stable build is a > prerequisite for any time based model. But like all things, this is a smell > that we have to do this... The other thing is that specifying a date or a > window of time in my opinion is crucial to ensuring freshly baked features > are not merged until we cut the release. The window need not be very long a > day or two as an example. With the volume of defects that we need to > assess/fix maintaining control of develop seems important. So I would > propose that we give notice of when we are looking to cut the branch (once we > have made adequate determinations for the defects). > >Thanks, >Mark > >On 12/18/20, 12:09 PM, "Owen Nichols" wrote: > >To summarize this thread so far: >@Robert and @Jens seem to favor “cut then stabilize” >@Alexander and @John seem to favor “stabilize then cut” >No one seems to favor “cut on a predetermined date” (at least for 1.14) > >@John also made a creative suggestion that maybe 1.14 doesn’t have to > be cut from latest develop…what if we cut it from support/1.13 and then > backport just the redis changes (in parallel with continuing to stabilize > what’s currently on develop into a 1.15 release). > >For now let’s try to proceed on the “stabilize then cut” plan. All > committers, please hold off on merging big refactorings or other high-risk > changes to develop until after the branch is cut. Let’s regroup next month > and try to clarify exactly which GEODE Jira tickets we need to focus on to > make sure 1.14 is our best release. > >From: Owen Nichols >Date: Tuesday, December 1, 2020 at 12:26 PM >To: dev@geode.apache.org >Subject: Re: [DISCUSS] Geode 1.14 >If someone wants to propose a list of must-fix Jira tickets before we > can cut the branch, I see that as a shift from a time-based to feature-based > branch-cut strategy. Might be fun to try? > >Given the distributed nature of the Geode community, picking a date > and sticking to it allows decentralized decision-making (each contributor can > plan on their own what they can finish and/or how they can help get develop > as stable as possible by that date). > >To answer your question: the current state of develop feels “pretty > good” to me. Knowing that only critical fixes will be allowed onto the > branch once cut, the question is really about features. It sounds like there > is redis work we’d like to ship. Anything else nearly-done we should > considering waiting on? > >From: Alexander Murmann >Date: Monday, November 30, 2020 at 11:57 AM >To: dev@geode.apache.org >Subject: Re: [DISCUSS] Geode 1.14 >Hi all, > >Thanks, Owen for reminding us all of this topic! > >I wonder how we feel about the state of develop right now. If we cut > 1.14 right now, it will make it easier to stabilize and ship it. However, I > see 21 open JIRA tickets affecting 1.14.0. It might be better to have an > all-hands effort to address as much as possible on develop and then cut 1.14. > If we shift all attention to 1.14, develop will likely never get better. I'd > love to get closer to an always shippable develop branch. That should vastly > reduce future release pain and make everyday development better as well. > >Thoughts? > >From: Jens Deppe >Sent: Wednesday, November 25, 2020 20:11 >To: dev@geode.apache.org >Subject: Re: [DISCUSS] Geode 1.14 > >Hi Owen, > >Thanks for starting this conversation and especially for volunteering > as Release Manager! > >Since we're already a couple of quarters 'behind', in terms of > releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means > we'll have 9 months of changes to stabilize. How long might that take to > finally get shipped? (rhetorical). > >--Jens > >On 11/25/20, 6:05 PM, "Owen Nichols" wrote: > >The trigger in @Alexander’s July 28 proposal to postpone 1.14 has > been met (we shipped 1.13). >It’s time to discuss when we want to cut the 1.14 branch. I will > volun
Re: [DISCUSS] Geode 1.14
My recommendation will be: - Identify, Prioritize, Merge 1.14 related work - Stabilize. Cut the branch and Stabilize again (to test any new changes added during first stabilize period) -Anil. On 12/18/20, 2:26 PM, "Mark Hanson" wrote: I support the cut on a predetermined date. But I will be ok with the Stabilize first approach, because I think that having a stable build is a prerequisite for any time based model. But like all things, this is a smell that we have to do this... The other thing is that specifying a date or a window of time in my opinion is crucial to ensuring freshly baked features are not merged until we cut the release. The window need not be very long a day or two as an example. With the volume of defects that we need to assess/fix maintaining control of develop seems important. So I would propose that we give notice of when we are looking to cut the branch (once we have made adequate determinations for the defects). Thanks, Mark On 12/18/20, 12:09 PM, "Owen Nichols" wrote: To summarize this thread so far: @Robert and @Jens seem to favor “cut then stabilize” @Alexander and @John seem to favor “stabilize then cut” No one seems to favor “cut on a predetermined date” (at least for 1.14) @John also made a creative suggestion that maybe 1.14 doesn’t have to be cut from latest develop…what if we cut it from support/1.13 and then backport just the redis changes (in parallel with continuing to stabilize what’s currently on develop into a 1.15 release). For now let’s try to proceed on the “stabilize then cut” plan. All committers, please hold off on merging big refactorings or other high-risk changes to develop until after the branch is cut. Let’s regroup next month and try to clarify exactly which GEODE Jira tickets we need to focus on to make sure 1.14 is our best release. From: Owen Nichols Date: Tuesday, December 1, 2020 at 12:26 PM To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 If someone wants to propose a list of must-fix Jira tickets before we can cut the branch, I see that as a shift from a time-based to feature-based branch-cut strategy. Might be fun to try? Given the distributed nature of the Geode community, picking a date and sticking to it allows decentralized decision-making (each contributor can plan on their own what they can finish and/or how they can help get develop as stable as possible by that date). To answer your question: the current state of develop feels “pretty good” to me. Knowing that only critical fixes will be allowed onto the branch once cut, the question is really about features. It sounds like there is redis work we’d like to ship. Anything else nearly-done we should considering waiting on? From: Alexander Murmann Date: Monday, November 30, 2020 at 11:57 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 Hi all, Thanks, Owen for reminding us all of this topic! I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well. Thoughts? From: Jens Deppe Sent: Wednesday, November 25, 2020 20:11 To: dev@geode.apache.org Subject: Re: [DISCUSS] Geode 1.14 Hi Owen, Thanks for starting this conversation and especially for volunteering as Release Manager! Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical). --Jens On 11/25/20, 6:05 PM, "Owen Nichols" wrote: The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13). It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager. Below are all release dates since Geode adopted a time-based release cadence. Minor releases: 1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020 1.12 branch cut Feb 4 20201.12.0 shipped Mar 31 2020 1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019 1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019 1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24
