Skip to content
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

Closed
cespare opened this issue Dec 22, 2017 · 31 comments
Closed

x/build/version: promote to golang.org/dl/go1.N #23223

cespare opened this issue Dec 22, 2017 · 31 comments
Labels
Builders x/build issues (builders, bots, dashboards) FrozenDueToAge Proposal Proposal-Accepted
Milestone

Comments

@cespare
Copy link
Contributor

cespare commented Dec 22, 2017

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

go get golang.org/v/go1.8
go1.8 download

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.)

@broady
Copy link
Contributor

broady commented Jan 11, 2018

@andybons was interested in this, so assigning to him.

And yes, it's really a few steps:

  • create new "v" (or other, more descriptive name) repo
  • create new /v/ go-get handler for golang.org
  • populate "v" repo (backfill all reasonable released versions - probably just the ones that have sha256 hashes, though i can't remember if we backfilled the hashes, too. I think I backfilled GPG asc signature files)
  • optional: add automation for new versions???

@rsc
Copy link
Contributor

rsc commented Jan 22, 2018

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.

@rsc
Copy link
Contributor

rsc commented Jan 22, 2018

Nice idea by the way.

@rsc rsc modified the milestones: Proposal, Go1.11 Jan 22, 2018
@rsc rsc changed the title proposal: x/build/version: promote to /v x/build/version: promote to /v Jan 22, 2018
@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label Jan 22, 2018
@bradfitz
Copy link
Contributor

@andybons, thoughts on "go get golang.org/go1.11beta1" etc?

@andybons
Copy link
Member

no issue here. if you can't think of any possible collisions then i'm at a loss for any as well :)

@dmitshur
Copy link
Contributor

dmitshur commented Jun 20, 2018

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.

@josharian
Copy link
Contributor

We need the opposite of a 410: will be available someday.

@dmitshur
Copy link
Contributor

dmitshur commented Jun 20, 2018

Some reasons why we might want to include a /v/ (or another name) path element:

  1. The alternative precludes placing all the individual go... commands in a single git repository. Each command would have to be a separate git repository. This is because the parent directory (golang.org) cannot be a git repository, since it would conflict/overlap with the golang.org/x/{net,image,tools,mobile,...} repositories.

    This isn't a factor if we do want to make each one a separate git repository, but I suspect we’d prefer to group them all under one repository.

  2. Having a parent directory, other than golang.org, can be used as an "index" page that lists all the go... commands. It would be similar to the listing at https://godoc.org/golang.org/x/build/version#pkg-subdirectories.

  3. Right now, $GOPATH/src/golang.org contains only the x directory. Having all the go... directories at the top level may seem untidy. This is subjective.

    image

@bradfitz
Copy link
Contributor

@shurcooL, good points.

I'm fine with /v/, but @rsc thought it was confusing.

Maybe we use get.golang.org/go1.11. But then it's:

$ go get get.golang.org/go1.11

Which stutters.

Any other domain? go get releases.golang.org/go1.11? Kinda long.

@josharian
Copy link
Contributor

Marginally shorter and arguably just as clear: release.golang.org/1.11

@andybons
Copy link
Member

or golang.org/v/1.11

@bradfitz
Copy link
Contributor

@andybons, golang.org/v/1.11 isn't good because it breaks the convention that the go get got thing matches the base name of the import path. One doesn't need to do that, but it's irregular if you don't. It'd be surprising to find that go get golang.org/v/1.11 puts go1.11 in your $PATH, and it'd be even more surprising that we'd name our binary 1.11 without the go prefix.

@agnivade
Copy link
Contributor

Could we use golang.org/dl/go1.11 ? This matches with our existing page for golang.org/dl and then adding a go1.11 makes the url go-gettable. Sounds nice to me. Also, has dl, so doesn't put everything at top-level.

Hmm .. but then we should decide what https://golang.org/dl/go1.11 should serve. It is possible that since golang.org/dl page shows all the downloads, people might expect https://golang.org/dl/go1.11 to return a ftp listing of all platform releases for that version.

Alternatively, the getgo tool uses get.golang.org, so it would be nice to use that for consistency. Though the stuttering thing might be an issue.

I just want to use something existing, rather than going with a new domain.

@bradfitz
Copy link
Contributor

@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

@agnivade
Copy link
Contributor

Perfect.

@andybons
Copy link
Member

I'm cool with that. Is that the plan?

@agnivade
Copy link
Contributor

It sure did sound like it 😄. paging @bradfitz for confirmation.

@bradfitz bradfitz changed the title x/build/version: promote to /v x/build/version: promote to golang.org/dl/go1.N Jul 10, 2018
@bradfitz
Copy link
Contributor

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.

@broady
Copy link
Contributor

broady commented Jul 10, 2018

+1 for new repo

@andybons
Copy link
Member

Let's do new repo. I'll do that.

@bradfitz
Copy link
Contributor

I created a new "dl" repo, but we need to configure the bots to watch the new "dl" repo, but work as begun:

https://go-review.googlesource.com/c/dl/+/123677

@gopherbot
Copy link

Change https://golang.org/cl/123678 mentions this issue: version: delete generator, add README

@gopherbot
Copy link

Change https://golang.org/cl/123679 mentions this issue: godoc/dl: add meta tags for go get golang.org/dl/go1.N

gopherbot pushed a commit to golang/build that referenced this issue Jul 13, 2018
Updates golang/go#23223

Change-Id: I98eb37fc572235ad4eb6e0bd6e687c308c99b4a9
Reviewed-on: https://go-review.googlesource.com/123678
Reviewed-by: Andrew Bonventre <andybons@golang.org>
@gopherbot
Copy link

Change https://golang.org/cl/123677 mentions this issue: all: copy+update code from x/build/version/*

gopherbot pushed a commit to golang/tools that referenced this issue Jul 20, 2018
Updates golang/go#23223

Change-Id: I628cea181d3a0e6bb25fdd98e098581aa222e049
Reviewed-on: https://go-review.googlesource.com/123679
Reviewed-by: Andrew Bonventre <andybons@golang.org>
@gopherbot
Copy link

Change https://golang.org/cl/125175 mentions this issue: godoc/dl: add meta tags for go get golang.org/dl/go1.N

gopherbot pushed a commit to golang/tools that referenced this issue Jul 20, 2018
…/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
@gopherbot
Copy link

Change https://golang.org/cl/125195 mentions this issue: godoc/dl: also serve go-import meta tags at golang.org/dl for cmd/go

gopherbot pushed a commit to golang/tools that referenced this issue Jul 20, 2018
Updates golang/go#23223

Change-Id: Iacecbb5e095fd3d6acb3f8e1fb238db63d1e0b6d
Reviewed-on: https://go-review.googlesource.com/125195
Reviewed-by: Andrew Bonventre <andybons@golang.org>
@gopherbot
Copy link

Change https://golang.org/cl/125176 mentions this issue: [release-branch.go1.10] godoc/dl: also serve go-import meta tags at golang.org/dl for cmd/go

@bradfitz
Copy link
Contributor

This is live & working, so closing this.

There might be follow-up work (as always), but it seems mostly done.

gopherbot pushed a commit to golang/tools that referenced this issue Jul 20, 2018
…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
@gopherbot
Copy link

Change https://golang.org/cl/133896 mentions this issue: maintner/maintnerd, cmd/gerritbot, cmd/gitmirror: add golang/dl to whitelist

gopherbot pushed a commit to golang/build that referenced this issue Sep 7, 2018
…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>
gopherbot pushed a commit to golang/dl that referenced this issue Sep 7, 2018
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>
@gopherbot
Copy link

Change https://golang.org/cl/144617 mentions this issue: version: make golang.org/dl replacement more visible

gopherbot pushed a commit to golang/build that referenced this issue Oct 25, 2018
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>
@gopherbot
Copy link

Change https://golang.org/cl/148881 mentions this issue: version: convert to generated copy of golang.org/dl/internal/version

gopherbot pushed a commit to golang/build that referenced this issue Dec 11, 2018
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>
@golang golang locked and limited conversation to collaborators Nov 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Builders x/build issues (builders, bots, dashboards) FrozenDueToAge Proposal Proposal-Accepted
Projects
None yet
Development

No branches or pull requests

9 participants