x/website: document release-branch & git branch policy

[rremer]

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 [email protected]: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]

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]

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