I made a first attempt at TINKERPOP-1825, but it wasn't as easy to fix as I thought initially. As we already talked about a bit in that ticket, I think that the .NET GLV generation would benefit from a bigger clean-up as that code is really confusing which makes every change to the GLV rather complicated. But feel free to tackle this ticket if you want.
I think that we should also try to get TINKERPOP-1745 and maybe TINKERPOP-1696 in before the official release of the .NET GLV as those are breaking changes, but I wouldn't necessarily consider those as blockers for a release. In general I'm also definitely +1 on a release as soon as we have the .NET test suite in. Am 30.11.2017 um 17:01 schrieb Jorge Bay Gondra: > There is one ticket I'd like to include related to .NET GLV: TINKERPOP-1825 > (includes API changes, related to code generation). I don't know if Florian > wanted to tackle it, otherwise I could work on it early next week. > > Besides that, I'm +1 on releasing once .NET test suite is merged. > > On Thu, Nov 30, 2017 at 1:52 PM, Stephen Mallette <spmalle...@gmail.com> > wrote: > >> I'd like to propose that we do a release before the end of the year. Now >> that the GLV Test Suite is largely in place and we're close to having .NET >> running under that suite we have a reasonable degree of confidence to make >> that release official and get off the release candidate system we've been >> using. It would further be good to get official releases of Gremlin Python >> out there as the release candidates for 3.3.1 and 3.2.7 have been out for >> about a month now without any report of trouble so those should be ready to >> go. >> >> Aside for GLV related changes there are a fair number of bug fixes and the >> import feature of math() step that need to get out into the wild. >> >> Other than existing open PRs >> >> https://github.com/apache/tinkerpop/pull/758 (.NET DSLs) >> https://github.com/apache/tinkerpop/pull/754 (.NET test suite) >> >> I'm not aware of any major issues that need to be closed before release, >> but I don't think we need to be in a huge rush to go to code freeze. Please >> raise any issues or concerns that you feel are relevant to 3.3.1 and 3.2.7 >> and we'll figure out where to go from here. >> >> Thanks, >> >> Stephen >>
