Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
website: document release-branch & git branch policy #18005
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 (
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.