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