Should today be 2.0.0rc0 or 2.0.0b4? All the featu...
# announce
h
Should today be 2.0.0rc0 or 2.0.0b4? All the feature work should be done within this release, once I land gRPC. I believe there are a few bugs we know about: • some Pex issues John has been working on • Ctrl-c issues Greg is working on
Cc @happy-kitchen-89482 @hundreds-breakfast-49010 @enough-analyst-54434 John, do you have an ETA for the next Pex release? I can wait to do the Pants release till the weekend or Monday, we should include the proxy fixes so Thales can upgrade
f
If there are still ctrl-c issues, I would call this b4
h
+1
h
I think greg merged the ctrl-c fix
h
It resulted in repl being really laggy. But he fixed that last night iiuc by reverting the ctrl-c fix. I’m not sure where we’re at
e
The 2.1.18 release should be this afternon: https://github.com/pantsbuild/pex/issues/1053 Have 1 item to be reviewed, one I'm still working on.
👍 1
h
I believe he has a narrower fix for just the repl issue, maybe that's not merged yet
h
the narrower fix for the repl issue was https://github.com/pantsbuild/pants/pull/10930, which is merged
👍 1
I havne't been able to find any cases so far where ctrl-c really breaks now, although in the medium-term I still think getting that port to the rust nailgun client, and then using heartbeats, and then switching away from the signal-based mechanism for controlling pantsd will be useful
but that should be an after-2.0.0 thing
h
OK so sounds like we can close the signal handling issue!
Cool so we have one remaining 2.0.0 blocker, which is the grpc support
👍 1
And @hundreds-father-404, sounds like you're on top of that
h
Okay so this should be rc0? Cool
e
https://github.com/pantsbuild/pants/pull/10938 concludes the Pex activity needed on the Pants side.
h
Thank you, John!
e
You're welcome. That's in master now.
h
Thanks. @happy-kitchen-89482 are you aiming to get your setup.py change improvement in rc0? I’m putting up the
s/python_binary/pex_binary
change in a few moments
h
No, I don't think so, still figuring out what it should look like.
Might cherry pick it to rc1
👍 1
h
Are we making a release branch for 2.0, or keep using the master branch?
f
we should make a release branch, there may be small fixes we do for 2.0.X releases, right?
leaving
master
free to have more fundamental changes for 2.1.x
h
The main question is if we will be making fundamental changes intended for 2.1.x in the next week or two, in which we’re focused almost exclusively on getting out 2.0.0 For example, I don’t suspect we’re going to do a 2.1.0.dev0 release until 2.0.0 is released
f
I’d want to add remote caching this week onto
master
if possible. Already wrote most of the code.
and that should not end up in 2.0.0 given the late stage
h
Okay, that’s reasonable. Thanks
h
Yeah, release branch is the normal thing we do for an rc, so we should do that here.