Given that this is a blocker for JanusGraph and potentially for other providers / users who use EventStrategy, I'm also in favor of releasing 3.5.1 shortly.
We can also start with the code freeze shortly from my side. I don't really see anything that we have to wait for. > As an aside, if we are going down this path, I wonder if we shouldn't > canary a 3.5.1.alpha of gremlint to see how the deploy process works > to npm...any concerns? Sounds like a good idea to me. I could handle the release in general this time. But I would only be available until July 27 as I will be on vacation afterwards. So, release on July 26 would work for me, but not later than that. I then also need to figure out shortly how to set up my system to build the docs. I have only done that with Docker so far and the one time I tried to set up Hadoop in the WSL to build the docs I ran into some issues that are related to the WSL if I remember correctly. I could probably alternatively also set up a dev env on some cloud VM if I can't get it to work on my machine. So if someone else wants to volunteer, then I would prefer that as I would then have a bit more time to set up Hadoop on my machine and we also would be a bit more flexible regarding the release date in case we run into anything that could delay the release. -----Ursprüngliche Nachricht----- Von: Oleksandr Porunov <[email protected]> Gesendet: Montag, 5. Juli 2021 23:47 An: [email protected] Betreff: Re: TinkerPop 3.5.1 Hi Stephen, > EventStrategy users won't be able to use the 3.5.x line without a release of > 3.5.1. So, I think that's the main issue here. I would have liked to have > seen 3.5.1/3.4.12 bake a bit longer but i'm not against getting into a > release discussion now as things are. As noted in the PR for JanusGraph 0.6.0 release, there are some users which are actually using `EventStrategy`. Thus, I believe it would be great if they could upgrade to a newer TinkerPop version without loosing that feature. I would be for releasing TinkerPop 3.5.1 sooner then later even if it lacks some additional features. > has JanusGraph tested against the 3.5.1-SNAPSHOT to be sure the fix resolves > issues there at this point? the latest snapshot has been published with that > fix at this point. i think that should be wholly confirmed before we actually > go to code freeze - Oleksandr, is that something you can help do and report > back on this thread? I have tested the latest JanusGraph commit from master branch (https://github.com/JanusGraph/janusgraph/commit/c1b11d4b848303ae0a2df102123fe018abad18d2) with the TinkerPop 3.5.1-SNAPSHOT as well as TinkerPop 3.5.0. I used both tests noted by Pavel here (called `test` and `event`): https://issues.apache.org/jira/browse/TINKERPOP-2579?focusedCommentId=17364795&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17364795 The results are the next: TinkerPop 3.5.0 with JanusGraph (CQL, Inmemory, BerkleyDB backends) - fails; TinkerPop 3.5.0 with TinkerGraph - fails; TinkerPop 3.5.1-SNAPSHOT with JanusGraph (CQL, Inmemory, BerkleyDB backends) - passes; TinkerPop 3.5.1-SNAPSHOT with TinkerGraph - passes; Based on that testing I confirm that TinkerPop 3.5.1-SNAPSHOT works with JanusGraph 0.6.0-SNAPSHOT. > The benefit of releasing 3.5.1 now would also be to get the first release of > gremlint out and put out javascript tx() support which should merge soon. I > was hoping we'd get python in as well on 3.5.1 but if that has to wait for > 3.5.2 that's fine I suppose. Ideally, we should get all variants running tx() > by 3.5.2 and try to release that in the next couple of months or sooner. So > releasing 3.5.1 now will mean we'll have a bit of a back to back release. > Again, not bad, just something to consider. I think splitting that work between 3.5.1 and 3.5.2 makes sense as TinkerPop can get early feedback / tests of `tx` feature for javascript. Moreover, as this is a new feature, I don't think it will block anybody but releasing TinkerPop 3.5.1 earlier would help JanusGraph to make the release with TinkerPop 3.5.x support. > If we do go have consensus on a 3.5.1 release when would we start code > freeze: 7/9 which if all went well would put release on July 26? I think 7/9 makes sense. > Also, are there volunteers to handle release manager duties this time around > (i can be around to assist, but i'd rather not be primary on this one)? I personally neither Apache member nor active TinkerPop committer, so I don't think I can be a release manager for TinkerPop but I know that Florian Hockmann was interested in JanusGraph 0.6.0 and he is both an Apache member and TinkerPop active committer. Moreover he was a release manager for JanusGraph 0.4.0. I believe he would be a great candidate for this release but I didn't ask him about it and I don't know if he has time / will to be a release manager for TinkerPop 3.5.1. Of course, if there are anyone volunteers for this release, that would be great but otherwise we could ask Florian to see what he thinks about it. Best regards, Oleksandr Porunov On 2021/07/02 20:46:47, Stephen Mallette <[email protected]> wrote: > Given how I read the comments on that PR there might be some confusion. > Just to be clear that issue of TINKERPOP-2579 was marked as a blocker > for release of 3.5.1, as in we wouldn't release without that being > done and not that it blocked folks from using 3.5.0. The workaround > for providers upgrading should be fine for release under 3.5.0, but > EventStrategy users won't be able to use the 3.5.x line without a > release of 3.5.1. So, I think that's the main issue here. I would have > liked to have seen 3.5.1/3.4.12 bake a bit longer but i'm not against > getting into a release discussion now as things are. > > has JanusGraph tested against the 3.5.1-SNAPSHOT to be sure the fix > resolves issues there at this point? the latest snapshot has been > published with that fix at this point. i think that should be wholly > confirmed before we actually go to code freeze - Oleksandr, is that > something you can help do and report back on this thread? > > The benefit of releasing 3.5.1 now would also be to get the first > release of gremlint out and put out javascript tx() support which > should merge soon. I was hoping we'd get python in as well on 3.5.1 > but if that has to wait for 3.5.2 that's fine I suppose. Ideally, we > should get all variants running tx() by 3.5.2 and try to release that > in the next couple of months or sooner. So releasing 3.5.1 now will > mean we'll have a bit of a back to back release. Again, not bad, just > something to consider. > > If we do go have consensus on a 3.5.1 release when would we start code > freeze: 7/9 which if all went well would put release on July 26? Also, > are there volunteers to handle release manager duties this time around > (i can be around to assist, but i'd rather not be primary on this one)? > > As an aside, if we are going down this path, I wonder if we shouldn't > canary a 3.5.1.alpha of gremlint to see how the deploy process works > to npm...any concerns? > > > > On Thu, Jul 1, 2021 at 10:41 AM Oleksandr Porunov < > [email protected]> wrote: > > > Hello, > > > > I would like to propose starting a release 3.5.1. > > The main purpose for that is because it has an important bug fix: > > https://issues.apache.org/jira/browse/TINKERPOP-2579 > > This bug affects shipping JanusGraph 0.6.0 release as discussed here: > > https://github.com/JanusGraph/janusgraph/pull/2672 > > > > Currently based on changelog I see that TinkerPop 3.5.1 version > > contains 2 bugfixes and 2 improvements as well as all changes from 3.4.12 > > release. > > > > I believe that should be a good reason for the release. Hope to hear > > some thoughts about it. > > > > Best regards, > > Oleksandr Porunov > > >
