7 ms·

Do any teams in Google write a human readable change log? The only one I know of that comes close is the Chrome team, which gets by with a blogspot[1] that som

Do any teams in Google write a human readable change log? The only one I know of that comes close is the Chrome team, which gets by with a blogspot[1] that sometimes has nice lists of the changes (sometimes in list form, sometimes in a paragraph with loads o' commas), and sometimes says stuff like: > A partial list of changes in this build is available in the SVN revision log http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/branches/1750_132/src&range=253861:254028&mode=html http://build.chromium.org/f/chromium/perf/dashboard/ui/chang... And here with Go 1.2.1 we get this[2]. It's not a huge deal in this case, but if you release a version and link to it and want us to know why its significant, it would be nice to find out why in English instead of SVN-ese. Compare this to the great, readable version that Firefox offers[3] ~~~ [1] http://googlechromereleases.blogspot.com/ http://googlechromereleases.blogspot.com/ [2] https://code.google.com/p/go/source/list?name=release-branch.go1.2&r=7ada9e760ce34e78aee5b476c9621556d0fa5d31 https://code.google.com/p/go/source/list?name=release-branch... [3] https://www.mozilla.org/en-US/firefox/27.0.1/releasenotes/ https://www.mozilla.org/en-US/firefox/27.0.1/releasenotes/

elithrar 13y ago
Go's major releases typically get a human readable changelog: http://golang.org/doc/go1.2 http://golang.org/doc/go1.2 - but yes, something for the point releases would be nice but probably not worth the time.
enneff 13y ago
Hey, so this would be my job, I guess. The reason I don't bother writing a separate change log is that I'd end up duplicating what the 5 changes on that page (above 1.2, the previous release) already say. All are subtle things that are of little meaning to most people, so I figure those that really care are going to read the changes anyway. Maybe I should revisit this next minor release. I should note that there is WAY more in that Firefox point release than in any Go point release. We strictly include only critical fixes for issues for which there is no workaround. For Go point releases, most people should just install them and move on. For 99.9% of Go programmers there is "nothing to see here". As has been already mentioned, we do provide a detailed change log for major releases: http://golang.org/doc/go1.2 http://golang.org/doc/go1.2 http://golang.org/doc/go1.1 http://golang.org/doc/go1.1
- simonsarris 13y ago
  I suppose that's a fair response, but at the risk of being rude please consider some advice from a marketing perspective. > All are subtle things that are of little meaning to most people... If the changes do have little to no meaning in themselves, it's important to consider: Why did you submit it, and why does it sit at the top of HN? HN didn't upvote it because of the changelog itself. There's nothing there. HN upvoted it because HN wants to know more about what's going on with Go. So what's really happened, is that HN is affording you a great opportunity here, but the contents of the post are sorta clutching defeat from the jaws of victory. I think we could both agree that Go is a great language that we want people to be excited about, and releases can make good front-of-mind advertising at the very least. If making the release announcements is part of your job then I think you should take it on yourself to get the prospective audience excited. Tell us everything that's happened since 1.2, including reminding us of any major advances surrounding go. Here's what people want to hear: The Go team is plugging along. Go is getting more dependable than ever. Here's what we're doing with Go, by the way. Here's the latest projects. Here's the latest tools. Don't just say the changes since 1.2, tell us everything in your ecosystem that's changed. Teach us to long for the immensity of the sea, as it were[1]. [1] https://gist.github.com/simonsarris/9318374 https://gist.github.com/simonsarris/9318374
  - enneff 13y ago
    My goal with the mailing list post and the submission was to let as many Go users as possible that a new release is out and they should upgrade. Should I use a minor release announcement as an occasion to get people more excited about Go? I'm not sure. I like the short and sweet nature of these point releases, and I'm wary of turning them into a marketing exercise. Otherwise, I do spend a lot of time telling people what's going on with Go. For instance, my presentation on what's new in Go 1.3 was at the top of HN for a day. Appreciate the feedback, though.
    - bsdetector 13y ago
      So how is this different from any other spammer? You're get paid to use Hacker News as a Go mouthpiece to promote your product every chance you can take. The reason why you, a Google employee working on Go, shouldn't be submitting these stories is because you have a clear conflict of interest. You think that 5 changes totaling a few dozen lines of code is worth everybody's attention because you're in the thick of it. But really, a story like this being front page I think calls into question whether there is a voting ring or voting bot; I can't imagine more than a person or two actually looked at the changes and said this is important.

elithrar 13y ago

Go's major releases typically get a human readable changelog: http://golang.org/doc/go1.2 http://golang.org/doc/go1.2 - but yes, something for the point releases would be nice but probably not worth the time.

enneff 13y ago

Hey, so this would be my job, I guess. The reason I don't bother writing a separate change log is that I'd end up duplicating what the 5 changes on that page (above 1.2, the previous release) already say. All are subtle things that are of little meaning to most people, so I figure those that really care are going to read the changes anyway. Maybe I should revisit this next minor release. I should note that there is WAY more in that Firefox point release than in any Go point release. We strictly include only critical fixes for issues for which there is no workaround. For Go point releases, most people should just install them and move on. For 99.9% of Go programmers there is "nothing to see here". As has been already mentioned, we do provide a detailed change log for major releases: http://golang.org/doc/go1.2 http://golang.org/doc/go1.2 http://golang.org/doc/go1.1 http://golang.org/doc/go1.1

simonsarris 13y ago
I suppose that's a fair response, but at the risk of being rude please consider some advice from a marketing perspective. > All are subtle things that are of little meaning to most people... If the changes do have little to no meaning in themselves, it's important to consider: Why did you submit it, and why does it sit at the top of HN? HN didn't upvote it because of the changelog itself. There's nothing there. HN upvoted it because HN wants to know more about what's going on with Go. So what's really happened, is that HN is affording you a great opportunity here, but the contents of the post are sorta clutching defeat from the jaws of victory. I think we could both agree that Go is a great language that we want people to be excited about, and releases can make good front-of-mind advertising at the very least. If making the release announcements is part of your job then I think you should take it on yourself to get the prospective audience excited. Tell us everything that's happened since 1.2, including reminding us of any major advances surrounding go. Here's what people want to hear: The Go team is plugging along. Go is getting more dependable than ever. Here's what we're doing with Go, by the way. Here's the latest projects. Here's the latest tools. Don't just say the changes since 1.2, tell us everything in your ecosystem that's changed. Teach us to long for the immensity of the sea, as it were[1]. [1] https://gist.github.com/simonsarris/9318374 https://gist.github.com/simonsarris/9318374
- enneff 13y ago
  My goal with the mailing list post and the submission was to let as many Go users as possible that a new release is out and they should upgrade. Should I use a minor release announcement as an occasion to get people more excited about Go? I'm not sure. I like the short and sweet nature of these point releases, and I'm wary of turning them into a marketing exercise. Otherwise, I do spend a lot of time telling people what's going on with Go. For instance, my presentation on what's new in Go 1.3 was at the top of HN for a day. Appreciate the feedback, though.
  - bsdetector 13y ago
    So how is this different from any other spammer? You're get paid to use Hacker News as a Go mouthpiece to promote your product every chance you can take. The reason why you, a Google employee working on Go, shouldn't be submitting these stories is because you have a clear conflict of interest. You think that 5 changes totaling a few dozen lines of code is worth everybody's attention because you're in the thick of it. But really, a story like this being front page I think calls into question whether there is a voting ring or voting bot; I can't imagine more than a person or two actually looked at the changes and said this is important.