Yah, today I saw that the CL had a larger impact than I originally thought.
Glad to see the fix is already there for Go 1.6.1 along with a new test.

Usually the x.y.1 releases don't come out right away. Do you expect 1.6.1
will come out fairly soon to resolve out-of-the-box http2 support?

Either way, I think I need to pull in x/net/http2 for what I'm doing, so
I'm certainly not in any rush.

On 19 February 2016 at 12:30, Russ Cox wrote:

We broke the rule, and we shouldn't have. Our bad. If the CL had really
just been disabling a corner case, I think that would not be a significant
change. But both Brad and I missed that the CL did more.

The bar is *slightly* lower for new functionality than functionality
carried from a previous release. Although we released with less HTTP/2 than
we should have, it was still not a regression from Go 1.5. We wouldn't have
even considered the change if HTTP/2 had been in 1.5.


On Thu, Feb 18, 2016 at 10:21 PM, Nathan Youngman wrote:


Thanks for all the work getting Go 1.6 out the door. It's a great
release. I've been using the http/2 support for a month or two and it's

Today I was caught off guard by a change between Go 1.6 rc2 and Go 1.6
final. I don't want to make a big deal, but thought I should mention it.

The Go Release Cycle wiki page states: "A release should not contain
significant changes since the last release candidate."

The change in question is this one "net/http: be more conservative about
enabling http2 on Transports":

Which caused a few users of my library to report the following issue:

So I guess my question is, what qualifies as a "significant" change?

I do think this is a fairly isolated case. I'm using the http/2 client
rather than server, and I require a certificate other than the default
root-ca. If my library and a handful of people are the only ones who
noticed, maybe the change isn't that significant.

In the end, I patched it up, and everything is fine. Life goes on, and
I'm happy that Go 1.6 is out for the release party celebration instead of
delayed by an rc3.

For future releases, I'm happy to run off tip and add tip to CI.


On Thursday, 28 January 2016 08:24:06 UTC-7, rsc wrote:

Go 1.7 will be a couple weeks shorter than usual, because Go 1.6 ran
long. This is now a pattern for our release cycles, one we need to break.
For Go 1.3, Go 1.4, Go 1.5, and Go 1.6, the first real beta was three,
four, five, and six weeks late respectively. We make up for it by rushing
the rest of the freeze, cutting from the time scheduled for polish,
production testing, and planning of the next release. Rushing the end is no
fun and also produces bad software, or at least software that isn't as good
as we would like.

This mail is about the release cycle and what we can do to make it work
better, both for delivering releases on time without rushing and for making
contributing to the project a better experience.

We've known about the delays for a while. At the beginning of the last
cycle I wrote:

We are also going to try to make sure we stay focused on issues and
pending CLs throughout the Go 1.6 cycle. Too many of both were left until
the freeze during Go 1.5. The new Go1.6Early milestone in GitHub is meant
to help, and I intend to set up a single automated weekly mail to
golang-dev reminding us what's pending, summarizing CLs, issues, and

We had trouble following through on that. One reason is that there
weren't enough of us on the Go team at Google handling incoming code
reviews and bug reports, including me being absent for a large chunk of the
time. We are going to try to make keeping up with code reviews and bugs
more of a focus this cycle, and we're going to be more realistic about
marking issues Unplanned if there's simply higher priority work to do.

Although I did experiment with a weekly automated mail to golang-dev, it
didn't really help because there were too many pending code reviews and
issues, so the mail was too large to be useful. I'd like to get the pending
CLs and issues cut to something reasonable early in the cycle, and then I
intend to try sending the weekly mails again to help maintain a reasonable
level. We'll see.

I think another reason for the schedule slips in the freeze is that
we've never clearly written down what the freeze means and what the
milestones inside the freeze are. It was clear to me even in December that
the release would be a few weeks late at the very least, by comparing where
we were to where we needed to be. I realized that we've never written down
the milestones that we have during the freeze that let me see that, so I
rewrote our Go Release Cycle wiki page <https://golang.org/s/release> to
have significantly more detail about targets during the cycle. The most
important part is that we can't just leave all bug triage and fixing to the
freeze. It has to be an ongoing process during the cycle. I want to break
explicitly the growing consensus that "fixing bugs is for the freeze."

That's what I see from my side of the release cycle, but I also want to
make sure the overall development process is working well for all of you,
our contributors. That's very important both to me and to the success of
the project.

I'd like to hear more, though, about what you think we should be doing
differently, what bothers you, and what would help you contribute more

If you have any suggestions about any of those topics or about how to
make the release cycle run more smoothly, or if you have comments on the
release cycle wiki page (really a first draft), please reply here on this
thread. (If for some reason you'd prefer not to reply publicly, it's okay
to write directly to me instead.)

Thanks very much.

You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nathan Youngman
Email: hello@nathany.com
Web: https://nathany.com

You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 7 | next ›
Discussion Overview
groupgolang-dev @
postedJan 28, '16 at 3:24p
activeFeb 19, '16 at 8:05p



site design / logo © 2022 Grokbase