-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/build/version: promote to golang.org/dl/go1.N #23223
Comments
@andybons was interested in this, so assigning to him. And yes, it's really a few steps:
|
If we do this, we should also deprecate/drop the old x/build/version names; maybe move this into a separate repo that doesn't have an x/ name at all when we switch to an official thing. The /v/ is a little confusing; Brad suggested just golang.org/go1.8, which is even nicer. Sounds fine in theory. Just needs to be prioritized with the rest of @andybons's team's work. |
Nice idea by the way. |
@andybons, thoughts on "go get golang.org/go1.11beta1" etc? |
no issue here. if you can't think of any possible collisions then i'm at a loss for any as well :) |
Worth thinking through: what will https://golang.org/go1.11beta1 serve? A 404? A redirect to the godoc.org page? Something else? I would expect the redirect to godoc.org, since that’s what https://golang.org/x/build/version/go1.10beta1 currently does. But I want to ask anyway. |
We need the opposite of a 410: will be available someday. |
Some reasons why we might want to include a /v/ (or another name) path element:
|
Marginally shorter and arguably just as clear: |
or |
@andybons, |
Could we use Hmm .. but then we should decide what Alternatively, the I just want to use something existing, rather than going with a new domain. |
@agnivade, oooh, that's kinda nice. The HTML for /dl/go1.10.3 could just redirect to e.g. https://golang.org/dl/#go1.10.3 |
Perfect. |
I'm cool with that. Is that the plan? |
It sure did sound like it 😄. paging @bradfitz for confirmation. |
Let's do it. Do we want a new repo for the "go1.N" commands or should we keep using x/build? I have a slight preference for a new repo. |
+1 for new repo |
Let's do new repo. I'll do that. |
I created a new "dl" repo, but we need to configure the bots to watch the new "dl" repo, but work as begun: |
Change https://golang.org/cl/123678 mentions this issue: |
Change https://golang.org/cl/123679 mentions this issue: |
Updates golang/go#23223 Change-Id: I98eb37fc572235ad4eb6e0bd6e687c308c99b4a9 Reviewed-on: https://go-review.googlesource.com/123678 Reviewed-by: Andrew Bonventre <andybons@golang.org>
Change https://golang.org/cl/123677 mentions this issue: |
Updates golang/go#23223 Change-Id: I628cea181d3a0e6bb25fdd98e098581aa222e049 Reviewed-on: https://go-review.googlesource.com/123679 Reviewed-by: Andrew Bonventre <andybons@golang.org>
Change https://golang.org/cl/125175 mentions this issue: |
…/dl/go1.N Updates golang/go#23223 Change-Id: I628cea181d3a0e6bb25fdd98e098581aa222e049 Reviewed-on: https://go-review.googlesource.com/123679 Reviewed-by: Andrew Bonventre <andybons@golang.org> (cherry picked from commit 827f47d) Reviewed-on: https://go-review.googlesource.com/125175
Change https://golang.org/cl/125195 mentions this issue: |
Updates golang/go#23223 Change-Id: Iacecbb5e095fd3d6acb3f8e1fb238db63d1e0b6d Reviewed-on: https://go-review.googlesource.com/125195 Reviewed-by: Andrew Bonventre <andybons@golang.org>
Change https://golang.org/cl/125176 mentions this issue: |
This is live & working, so closing this. There might be follow-up work (as always), but it seems mostly done. |
…olang.org/dl for cmd/go Updates golang/go#23223 Change-Id: Iacecbb5e095fd3d6acb3f8e1fb238db63d1e0b6d Reviewed-on: https://go-review.googlesource.com/125195 Reviewed-by: Andrew Bonventre <andybons@golang.org> (cherry picked from commit 99195f4) Reviewed-on: https://go-review.googlesource.com/125176
Change https://golang.org/cl/133896 mentions this issue: |
…itelist In golang/go#23223, we've created a new subrepository: https://go.googlesource.com/dl Unlike other subrepositories, there isn't a mirror on GitHub yet: https://github.com/golang/dl (404 at this moment) We want to include it in the whitelist for mirroring to GitHub, including mirroring its pull requests to Gerrit. The motivation is to make this subrepository consistent with all others and prevent people from running into an unexpected situation when some repos are mirrored but some aren't. We don't actually expect much contribution activity to the dl subrepo, because it's very narrow in scope and mostly generated code. Updates golang/go#26949. Change-Id: Id995bb3d97b8eb328e6c6bba6714bc74fbefb942 Reviewed-on: https://go-review.googlesource.com/133896 Reviewed-by: Andrew Bonventre <andybons@golang.org>
From x/build git rev a41435cbf9f. Renames the "version" package to internal/version too. Updates golang/go#23223 Change-Id: Idbcedeb5f3ac1f2afe527064be0d6ae8524a0358 Reviewed-on: https://go-review.googlesource.com/123677 Reviewed-by: Andrew Bonventre <andybons@golang.org>
Change https://golang.org/cl/144617 mentions this issue: |
The golang.org/x/build/version/... packages have been deprecated in favor of golang.org/dl/... in CL 123678, as part of golang/go#23223. Make this more visible by pointing to the new packages in the package documentation. Use a godoc.org link to avoid confusion, because these import paths are hard tell apart from normal URLs that have a different meaning. Updates golang/go#23635. Updates golang/go#23223. Change-Id: Ide6371f24fa2369b2807987c83df4226cacfe35d Reviewed-on: https://go-review.googlesource.com/c/144617 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change https://golang.org/cl/148881 mentions this issue: |
Package version has been copied from golang.org/x/build/version to golang.org/dl/internal/version as part of golang/go#23223. The old package was marked deprecated but kept for backwards compatibility reasons. Fixes and changes have not been backported from the new dl/internal/version package (to avoid spending time unproductively). bundle has recently been updated to accept an empty prefix in CL 105515. This allows one to use bundle to make a generated copy of a package. A generated copied package is better than a manually-maintained copied package for the following reasons: 1. Keeping the copied package up to date with upstream is low effort, just need to run go generate. 2. It's clear to contributors that the copied package isn't the canonical version, since there is a generated comment like "// Code generated by golang.org/x/tools/cmd/bundle. DO NOT EDIT." at the top of the file. It's easy to reject changes to the copied package, or redirect them to the upstream. Overall, making the copied package generated rather than hand-written reduces the maintenace cost, and makes it more viable to keep it more up to date with upstream. The diff to version.go in this CL is due to some dl/internal/version CLs being effectively backported by bundle, including CL 134435, CL 143545, and CL 144698. Updates golang/go#23223 Fixes golang/go#23635 Change-Id: Id8cd63c52b660b6817e6fdba080373966789e1e8 Reviewed-on: https://go-review.googlesource.com/c/148881 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
With #23207, we've started adding released Go versions to x/build/version as well. Since this has become the easiest way to install and run a whole family of Go versions, @broady suggested in #23207 (comment) that we move this tree up to x/version or /v, and @bradfitz gave a +1 for /v.
Then installing arbitrary Go versions would be as simple as
I don't know if this would entail creating a new go.googlesource.com repo or if it just involves updating the golang.org frontend configuration to direct /v requests appropriately. (If the latter, perhaps the old path could continue working.)
The text was updated successfully, but these errors were encountered: