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

proposal: x/all: start tagging versions #21324

Open
leonklingele opened this issue Aug 6, 2017 · 14 comments
Open

proposal: x/all: start tagging versions #21324

leonklingele opened this issue Aug 6, 2017 · 14 comments
Labels
Projects
Milestone

Comments

@leonklingele
Copy link
Contributor

@leonklingele leonklingele commented Aug 6, 2017

With the advent of tool like dep it makes sense to tag a specified release instead of referring to master or a specific commit.

@gopherbot gopherbot added this to the Unreleased milestone Aug 6, 2017
@ALTree ALTree changed the title x/crypto: Please create a tag x/crypto: start managing releases using git tags Aug 6, 2017
@ALTree
Copy link
Member

@ALTree ALTree commented Aug 6, 2017

It would be useful to have a common policy for all subrepos (or at least the ones for which it makes sense to publish "releases"), not just crypto.

@ALTree ALTree added the NeedsDecision label Aug 8, 2017
@rsc
Copy link
Contributor

@rsc rsc commented Aug 21, 2017

This discussion should be about all the subrepos, not just x/crypto.

@rsc rsc changed the title x/crypto: start managing releases using git tags proposal: x/all: start tagging versions Aug 21, 2017
@gopherbot gopherbot added the Proposal label Aug 21, 2017
@rsc
Copy link
Contributor

@rsc rsc commented Aug 21, 2017

There is also a question of how to decide the right version number, when to bump major version, what tagging implies (any particular testing), and so on. There are many issues here.

@rsc
Copy link
Contributor

@rsc rsc commented Oct 9, 2017

@mpvl was starting to look into this for x/text, which might be a good starting point.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Apr 30, 2018

One step is that we need to figure out how to split up the x/ repos into modules.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jul 16, 2018

On hold until Go 1.11 and/or Go 1.12. At least until we have tooling ready and some experience with said tooling.

@networkimprov
Copy link

@networkimprov networkimprov commented Aug 19, 2018

As a start, just maintain a semver tag for each package in golang.org/x/* (or at least in the mostly-stable repos), since a package is the unit of use in most cases. The natural starting semver is 1.0.0 (unless a package is considered unstable, in which case 0.1.0).

For now, let users create modules from tagged packages as needed. Eventually you may decide to bless certain of those modules.

You might want to add tags ASAP; the imminent rush of go mod users will complain if they have to ref commit IDs :-)

@gopherbot add modules

@thepudds
Copy link

@thepudds thepudds commented Oct 25, 2018

Related to #27858 and #28136.

@psampaz
Copy link
Contributor

@psampaz psampaz commented Nov 21, 2019

any updates in this? Is it still valid for this proposal to be on hold?

@itsmontoya
Copy link

@itsmontoya itsmontoya commented Mar 5, 2020

This is creating a lot of noise within go.sum files when many libraries utilize x/net and x/sys. In addition, it's creating difficulties when using go plugins due to differing versions (usually caused by x/net and x/sys). Do we have an update on when this is going to get implemented?

@ALTree
Copy link
Member

@ALTree ALTree commented Mar 5, 2020

@bradfitz wrote in 2018:

On hold until Go 1.11 and/or Go 1.12. At least until we have tooling ready and some experience with said tooling.

Now Go1.14 is out and we have a some experience on the module workflow, so I'm moving this from "on hold" to "Proposal" for re-evaluation.

@ALTree ALTree removed the Proposal-Hold label Mar 5, 2020
@networkimprov
Copy link

@networkimprov networkimprov commented Mar 5, 2020

The tag doesn't need to be a contrived x.y.z string. It could be 0.0.0-timestamp, posted after each new feature/fix.

@bcmills
Copy link
Member

@bcmills bcmills commented Mar 5, 2020

@networkimprov, isn't that essentially what we have with pseudo-versions today? (Or do you mean we should tag one of those after each significant change only?)

@networkimprov
Copy link

@networkimprov networkimprov commented Mar 6, 2020

Depends what you mean by "significant" but probably that; I didn't mean after each commit.
0.0.0-timestamp is a lot more meaningful than 0.0.0-SHA

You could limit the frequency to once a week/month/quarter etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Incoming
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.