Go: x/build/version: add released Go versions
x/build/version is an wonderful tool for easily running different Go versions. However, it only supplies the betas and rcs -- not released versions. I often need to check things against different released versions (especially when I'm running some tip build day-to-day).
How about adding released major/minor versions as well?
/cc @broady @bradfitz
If you're okay with it, I can send over a CL with all the released versions since, say, 1.8.
(I could of course host arbitrary versions myself but I figured that this would be broadly useful.)
cespare
All 9 comments
china GFW don't see
birdofprey
on 21 Dec 2017
@cespare, sounds good.
bradfitz
on 21 Dec 2017
Sounds good to me, too. What do you think about graduating it to its own x/
subrepo?
golang.org/x/version/go1.9.2
Or if we want to be very aggressive, golang.org/version/go1.9.2 or
golang.org/v/go1.9.2
Happy to backfill the versions (but it's a nice project for a new
contributor)
On Thu, Dec 21, 2017, 12:35 AM Brad Fitzpatrick notifications@github.com
wrote:
@cespare https://github.com/cespare, sounds good.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/23207#issuecomment-353262423, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABhlkWx4itRVQuOZHUZhzjvSYrJI6S5ks5tCe4wgaJpZM4RJWUA
.
broady
on 21 Dec 2017
I like /v/. File a proposal, or proposal-ify this bug?
bradfitz
on 21 Dec 2017
I also run tip, and I keep the latest stable, 1.9.x (installed via the distro's package manager), to bootstrap it and to test bugs. However, as @cespare says, this makes it tricky to also keep older or other specific versions of Go at the same time.
Being able to "go get" 1.8.x would be great.
mvdan
on 21 Dec 2017
Change https://golang.org/cl/85335 mentions this issue: version: add all released versions in [go1.8, go1.9.2]
gopherbot
on 22 Dec 2017
I mailed a CL and opened #23223 for the /v proposal.
Is there some kind of release checklist where we should add an entry for creating a new version file in this project?
cespare
on 22 Dec 2017
@cespare the release checklist is Google-internal (but mostly being replaced by releasebot). It's a good suggestion (it should be added as a step to releasebot, probably).
broady
on 11 Jan 2018
the release checklist is Google-internal
And note that that is not for nefarious reasons. We try to have close to zero internal-only resources, but in this particular case our release process involves signing binaries, which itself involves using internal systems to sign for us (since we don't have the private key to sign ourselves, which is a feature). I suppose we could publish a lazily synced & lazily maintained partially-scrubbed version of our internal doc, though. Feel free to file a separate bug for that if you're curious.
bradfitz
on 11 Jan 2018
Related issues
ajstarks
·
3Comments
OneOfOne
·
3Comments
rsc
·
3Comments
longzhizhi
·
3Comments
lkarlslund
·
3Comments
Most helpful comment
And note that that is not for nefarious reasons. We try to have close to zero internal-only resources, but in this particular case our release process involves signing binaries, which itself involves using internal systems to sign for us (since we don't have the private key to sign ourselves, which is a feature). I suppose we could publish a lazily synced & lazily maintained partially-scrubbed version of our internal doc, though. Feel free to file a separate bug for that if you're curious.