search

davecheney / httpstat

It's like curl -v, with colours.
MIT License
6.95k stars 382 forks source link

Golang 1.8 - Use ClientTrace.TLSHandshakeStart and TLSHandshakeDone #114

Closed wendigo closed 6 years ago

wendigo commented 7 years ago

Use ClientTrace.TLSHandshakeStart/HandshakeDone from incoming go 1.8: https://github.com/golang/go/commit/abdd73cc43f9187e8918879944ec0dacbc912b5c

This PR probably should be blocked until 1.8 is released

davecheney commented 7 years ago

Thanks for sending this. TBH I'm not going to look at this until 1.8 is out at the end of the year, and even then might ask you for a solution to keep backwards compat with go 1.7.

davecheney commented 7 years ago

Also, please raise an issue before slinging code. Thank you.

wendigo commented 7 years ago

Off-topic question @davecheney: what's your recommended approach to using version-specific golang APIs? Should it be avoided and support for previous golang versions must be provided or is it ok to use the most recent version when building and distributing open source software?

davecheney commented 7 years ago

Generally you have to break out the affected function and then implement it twice with // +build tags

On Sun, Oct 23, 2016 at 9:11 PM, Mateusz Gajewski notifications@github.com wrote:

Off-topic question @davecheney https://github.com/davecheney: what's your recommended approach to using version-specific golang APIs? Should it be avoided and support for previous golang versions must be provided or is it ok to use the most recent version when building and distributing open source software?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/davecheney/httpstat/pull/114#issuecomment-255580054, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA2TnLUNcEOfPQfpH7ONVEnCIj6Jxks5q2zLsgaJpZM4Kd6bM .

davecheney commented 7 years ago

As for the question about should you use the latest version of Go -- yes, you should always use the latest version of Go; previous ones have more bugs and are not supported.

On Sun, Oct 23, 2016 at 9:27 PM, Dave Cheney dave@cheney.net wrote:

Generally you have to break out the affected function and then implement it twice with // +build tags

On Sun, Oct 23, 2016 at 9:11 PM, Mateusz Gajewski < notifications@github.com> wrote:

Off-topic question @davecheney https://github.com/davecheney: what's your recommended approach to using version-specific golang APIs? Should it be avoided and support for previous golang versions must be provided or is it ok to use the most recent version when building and distributing open source software?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/davecheney/httpstat/pull/114#issuecomment-255580054, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA2TnLUNcEOfPQfpH7ONVEnCIj6Jxks5q2zLsgaJpZM4Kd6bM .

wendigo commented 7 years ago

Related to https://github.com/davecheney/httpstat/issues/113

rs commented 6 years ago

The .travis needs to be updated to use Go 1.8 so the CI don't fail. Then I guess @davecheney should be able to merge this.

davecheney commented 6 years ago

I’d rather a PR that updated the Travis setting to not test against 1.8. It’s not supported by the Go team, so we shouldn’t either

On 28 Apr 2018, at 05:34, Olivier Poitrey notifications@github.com wrote:

The .travis needs to be updated to use Go 1.8 so the CI don't fail. Then I guess @davecheney should be able to merge this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.