Thanks for sharing TINKERPOP-2169 as something to keep an eye on. Depending on the nature of the changes in the PR we could potentially merge it during code freeze. Let's see what the PR looks like. We definitely appreciate you working on that.
On Wed, Mar 6, 2019 at 11:42 AM Divij Vaidya <[email protected]> wrote: > Hello > > I was also hoping to merge in Tinkerpop-2169 (Java GLV & server changes) as > part of this release. I am actively working on it and should have the PR > out by early next week. > > These changes are not blocker for the release but I would like to get them > to hands of customers as soon as possible. > > On Wed, Mar 6, 2019 at 3:47 AM Stephen Mallette <[email protected]> > wrote: > > > Well....it technically applies to the entire code base though we've > > rationalized late changes to GLVs using the reasoning you provided. I > think > > that if the PR is in review on Friday that leave sufficient time to > > review/test if the changes must go in. If you're confident in the changes > > and they look good to merge early in code freeze week then I dont have > any > > real objections to allowing that to happen. Thanks for raising the issue > as > > something for us to consider. > > > > On Wed, Mar 6, 2019 at 5:02 AM Florian Hockmann <[email protected]> > > wrote: > > > > > Regarding code freeze: I vaguely remember that we didn't apply that to > > > GLVs once, but is that our general policy or was it only an exception? > > (The > > > reasoning was that the GLVs aren't used by providers to check a new > > release > > > if I remember it correctly.) > > > > > > I'm just asking because of these two .NET issues: TINKERPOP-2090 and > > > TINKERPOP-2135. (I have opened a PR for TINKERPOP-2135, but given the > > > discussion there and in the comments of TINKERPOP-2090, it could make > > sense > > > to address both in the same PR which would need some more work.) > > > We probably won't be able to fix them until Friday, but maybe until the > > > VOTE starts. I would categorize them as nice to have for 3.4.1, but > > nothing > > > that should delay the release as we can also just fix them with the > next > > > release. > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Stephen Mallette <[email protected]> > > > Gesendet: Dienstag, 5. März 2019 21:15 > > > An: [email protected] > > > Betreff: Re: [DISCUSS] proposed release of 3.3.6/3.4.1 > > > > > > Hi all, as we are now in the first full week of March I think we should > > > start firming up with the plan to release 3.3.6/3.4.1. I suggest that > we > > > begin code freeze week at close of business this Friday, March 8th and > > plan > > > for a VOTE the week of March 18th with the idea that we'll release by > end > > > of that week. I don't know of any super important issues we want to > close > > > out that aren't already PRs, but I imagine we'll want to merge the ones > > > that we currently have open. Please post back if there are any issues > you > > > think are important to watch and consider for this release. > > > > > > On Thu, Feb 21, 2019 at 2:34 PM Stephen Mallette <[email protected] > > > > > wrote: > > > > > > > Hello, after that large 3.4.0 release, I think it would be good to > get > > > > back to smaller/faster release cycles for a bit. I'd like to propose > > > > that we set up to release 3.4.1/3.3.6 sometime in mid-March. We have > a > > > > good body of fixes and optimizations in places already that I think > > > > people should start having access to. Please let me know if you have > > > > an objections and if not, we'll proceed down that path. Also, if you > > > > have any specific items that you think need to be done for this > > > > upcoming release please point them out so that we're aware of them. > > > > > > > > Thanks, > > > > > > > > Stephen > > > > > > > > > > > > > -- > Divij Vaidya >
