Re:Keeping your Go modules compatible
by ithkuil on Tuesday July 07, 2020 @05:42PM
(#23764428)
> Except we already had godep. It worked. It was in widespread use.
> un-eyeballable, merge-review-hostile, another-arbitrary-c-hacker-mini-language, shas-upon-shas version
godep shared the same problem.
We can argue that godep was good enough and the Go maintainers handled the situation poorly with this whole "ask community and then ignore the community" trick.
But you're focusing on the transition; if this system had been part of Go 1.0, I would have had nothing bad to say about it.
I'm not arguing the the transition process wasn't a mess.
I'm arguing that it became a mess precisely because they wanted to attempt backward compat.
They could have said "this is go 2; if you want to use your library with go 2 you have to use this standard, tag your release, or upload it to some central index"
> un-eyeballable, merge-review-hostile, another-arbitrary-c-hacker-mini-language, shas-upon-shas version
godep shared the same problem. We can argue that godep was good enough and the Go maintainers handled the situation poorly with this whole "ask community and then ignore the community" trick. But you're focusing on the transition; if this system had been part of Go 1.0, I would have had nothing bad to say about it.
I'm not arguing the the transition process wasn't a mess. I'm arguing that it became a mess precisely because they wanted to attempt backward compat. They could have said "this is go 2; if you want to use your library with go 2 you have to use this standard, tag your release, or upload it to some central index"