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

website: document release-branch & git branch policy #18005

Open
rremer opened this issue Nov 21, 2016 · 2 comments

Comments

@rremer
Copy link

commented Nov 21, 2016

This is a more general release strategy question.

I see that the git tag for 1.7.3 references a release branch 1release-branch.go1.7'. For work in progress (e.g. release candidates), this makes perfect sense, but considering 1.7.3 has been released, and binaries are advertised on golang.org for this version, I expected that this release branch would be merged with master.

I see https://github.com/golang/go/wiki/Go-Release-Cycle doesn't mention the process of branching for releases or when they're merged with master, and while I wouldn't want to get draconian on this process, I did want to express my surprise that I can no longer build golang stable releases without mirroring all branches from github.

If there's documentation on the release process somewhere else, I'd love to be told to shut up and go read it! If this is simply an oversight, perhaps a little documentation on the process would be helpful in keeping master/releases always synced up and tidy.

... somewhat irrelevant bug template questions answered below:

What version of Go are you using (go version)?

Affects 1.7, 1.7.1, 1.7.2, 1.7.3
... and future versions

What operating system and processor architecture are you using (go env)?

Linux 1d9c731ca9f1 3.13.0-96-generic #143-Ubuntu SMP Mon Aug 29 20:15:20 UTC 2016 x86_64 Linux

What did you do?

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
$ git clone git@github.com:golang/go.git
$ git tag | grep go1.7 | head -n 4
go1.7
go1.7.1
go1.7.2
go1.7.3
$ git push --mirror git@internal-git-endpoint-redacted/golang/go.git
$ cd ..
$ git tag | grep go1.7 | head -n 4
go1.7beta1
go1.7beta2
go1.7rc1
go1.7rc2

What did you expect to see?

git tag | grep go1.7 | head -n 4
go1.7
go1.7.1
go1.7.2
go1.7.3

What did you see instead?

git tag | grep go1.7 | head -n 4
go1.7beta1
go1.7beta2
go1.7rc1
go1.7rc2

...obviously I can push all branches, I just didn't expect I needed to track all upstream branches internally since I was only building stable releases (which I assumed falsely would always be on master).

@kardianos

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2016

The release branches are created from master. Subsequent fixes are then cherry-picked from master on to the release branch as needed. The branches are long lived as sometimes backports need to be applied for various reasons (a recent example was to ensure certain old versions support the new OSX).

By design branches will never be merged with master. If you are mirroring the go repo you will need to mirror any release branches as well.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 21, 2016

What @kardianos said. Perhaps there's something to document somewhere.

@bradfitz bradfitz added this to the Go1.9Maybe milestone Nov 21, 2016

@bradfitz bradfitz changed the title policy: merge to master with each major release website: document release-branch & git branch policy Nov 21, 2016

@ianlancetaylor ianlancetaylor modified the milestones: Go1.10, Go1.9Maybe Aug 3, 2017

@andybons andybons self-assigned this Jan 22, 2018

@ianlancetaylor ianlancetaylor modified the milestones: Go1.10, Go1.10.1 Feb 17, 2018

@andybons andybons modified the milestones: Go1.10.1, Unplanned Mar 27, 2018

@andybons andybons removed their assignment Mar 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.