Go 1.2 Release Candidate 1 released

[Andrew Gerrand]

Hi Go nuts,

We have just released go1.2rc1, a release candidate for Go 1.2. It is cut from the default branch at revision f4d1cb8d9a91.

This release candidate is NOT stable and should not be used in production systems.

Please help us by testing your Go programs with the new tool chain and libraries, and report any problems using the issue tracker:
    http://golang.org/issue/new

You can download binary and source distributions from the usual place:
    https://code.google.com/p/go/downloads/list?q=go1.1rc2

To find out what has changed, read the release notes for Go 1.2:
    http://tip.golang.org/doc/go1.2.html

Documentation for Go 1.2 is available at http://tip.golang.org/

Our goal is to release the official version of Go 1.2 on December 1, 2013.

Andrew

[Dan Kortschak]

I'm not seeing that tag in the pulled code or on the changes page at
p/go. Is this a lag or something else?

Dan

[minux]

On Fri, Sep 20, 2013 at 12:21 AM, Dan Kortschak <dan.ko...@adelaide.edu.au> wrote:

I'm not seeing that tag in the pulled code or on the changes page at
p/go. Is this a lag or something else?

see CL 13777043 and CL 13354049.

[Dan Kortschak]

Yes, I saw those when they went in. So it's an untagged rc?

[brainman]

On Friday, 20 September 2013 14:07:21 UTC+10, Andrew Gerrand wrote:

You can download binary and source distributions from the usual place:
    https://code.google.com/p/go/downloads/list?q=go1.1rc2

I think you meant to say https://code.google.com/p/go/downloads/list?q=go1.2rc1

Alex 

[minux]

On Fri, Sep 20, 2013 at 12:30 AM, Dan Kortschak <dan.ko...@adelaide.edu.au> wrote:

Yes, I saw those when they went in. So it's an untagged rc?

when cmd/dist sees the tag, it thinks it's a release version of Go, and will refuse to build

when cmd/prof is present. which means we probably can't tag go1.2rc1 without first

branch and delete cmd/prof.

[Dan Kortschak]

Would something like this be frowned upon?


diff -r 5b367120d592 src/cmd/dist/build.c
--- a/src/cmd/dist/build.c Thu Sep 19 17:12:00 2013 +1000
+++ b/src/cmd/dist/build.c Fri Sep 20 14:32:52 2013 +0930
@@ -404,7 +404,7 @@
}

// For release, make sure excluded things are excluded.
- if(hasprefix(goversion, "release.") || hasprefix(goversion, "go")) {
+ if(hasprefix(goversion, "release.") || (hasprefix(goversion, "go") && !contains(goversion, "rc"))) {
for(i=0; i<nelem(unreleased); i++)
if(isdir(bpathf(&b, "%s/%s", goroot, unreleased[i])))
fatal("%s should not exist in release build", bstr(&b));

[minux]

i think we need better detection for released version, consider that we also issue go1.2beta.

how about we check that the goversion either hasprefix "release." or match "go[0-9.]*"?

(anyway, please send the CL so that we can continue discussion on that CL.)

[Dave Cheney]

Would it be simpler to move cmd/prof to a sub repo ?

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

[minux]

On Fri, Sep 20, 2013 at 1:25 AM, Dave Cheney <da...@cheney.net> wrote:

Would it be simpler to move cmd/prof to a sub repo ?

then we will either have to re-introduce Makefile or teach cmd/dist to build cmd/prof in a subrepo. 

[Nathan Youngman]

Thanks Andrew. I look forward to trying out the new cgo changes with Xcode 5 installed. I'll just update to the SHA for now, no biggy.

If we are going to make cmd/dist more intelligent about recognizing release versions, could we go ahead and make the tags follow http://semver.org/

v1.2.0-rc.1
v1.2.0

Go already follows SemVer in spirit, might as well in letter. This is something I've been doing and recommending others do for third-party packages in order to have a consistent release tag format for tooling.

Thanks again. Nathan.

[Dan Kortschak]

On Fri, 2013-09-20 at 01:20 -0400, minux wrote:
> how about we check that the goversion either hasprefix "release." or
> match "go[0-9.]*"?

This would require (AFAICS) introduction of a match function to
cmd/dist.

[Nathan Youngman]

A simple ASCII search for a '-' hyphen could indicate a non-release version:

v1.2.0-rc.1
v1.2.0-beta
v1.2.0

Looking at existing tags

weekly.yyyy-mm-dd # non-release
go1 # release
go1.1.2 # release
release.r60.3 # release

The potentially problematic ones are:

go1.1rc2
go1.1rc3
weekly

[minux]

because it's so simple, i think it could be written a C function that take a couple of lines,

and no extra external dependencies.

[Keith Rarick]

I'm curious about the "-osx10.8" naming convention for the darwin builds.
I assume a change like this would not be made gratuitously.

The Heroku buildpack makes a halfhearted attempt to work on multiple OSes.
https://github.com/kr/heroku-buildpack-go/blob/7ce7f7d/bin/compile#L10

Is there a rule I can follow to reliably assemble a URL for both linux
and darwin?

[minux]

On Sep 20, 2013 3:12 PM, "Keith Rarick" <k...@xph.us> wrote:
>
> I'm curious about the "-osx10.8" naming convention for the darwin builds.
> I assume a change like this would not be made gratuitously.

please see issue 5726.

[Ian Lance Taylor]

On Fri, Sep 20, 2013 at 12:11 PM, Keith Rarick <k...@xph.us> wrote:
> I'm curious about the "-osx10.8" naming convention for the darwin builds.
> I assume a change like this would not be made gratuitously.
>
> The Heroku buildpack makes a halfhearted attempt to work on multiple OSes.
> https://github.com/kr/heroku-buildpack-go/blob/7ce7f7d/bin/compile#L10
>
> Is there a rule I can follow to reliably assemble a URL for both linux
> and darwin?

Well, which version of Darwin do you mean? We unfortunately have to
build different binary distributions for different versions of Darwin.

Ian

[Gustavo Niemeyer]

If you are in Ubuntu or Debian, please note that godeb [1] should still work:

http://paste.ubuntu.com/6134116/


[1] http://blog.labix.org/2013/06/15/in-flight-deb-packages-of-go

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



--

gustavo @ http://niemeyer.net

[Keith Rarick]

On Fri, Sep 20, 2013 at 12:17 PM, Ian Lance Taylor <ia...@golang.org> wrote:
>> https://github.com/kr/heroku-buildpack-go/blob/7ce7f7d/bin/compile#L10
>> Is there a rule I can follow to reliably assemble a URL for both linux
>> and darwin?
>
> Well, which version of Darwin do you mean? We unfortunately have to
> build different binary distributions for different versions of Darwin.

I see. Then I mean whichever version of Darwin that shell script
is running on at the time of execution.

It's not a big deal. I can live without Darwin support; it just makes
testing easier. (Heroku runtime is always Linux.) But if there's an
easy way to guess the right URL it would be nice to know.

[Keith Rarick]

Heroku users, as with Go version 1.1, I've added a go1.2 branch
to the buildpack. This branch currently pulling 1.2rc1, and I'll continue
updating it as new 1.2 releases come out.

To use it:

$ heroku config:set
BUILDPACK_URL='https://github.com/kr/heroku-buildpack-go#go1.2'
$ git push heroku master

Once Go 1.2 is released, I'll update the buildpack's master branch as well.

On Thu, Sep 19, 2013 at 9:07 PM, Andrew Gerrand <a...@google.com> wrote:

[ajstarks]

FYI, this release builds on the original 256MB Raspberry PI, but the tests fail with nilptr.go, rotate[1-3].go, fixedbugs/issue5162.go throwing incorrect output and out of memory errors.

[Dave Cheney]

I don't think there is much that can be done about that, those tests
do allocate a lot of memory, especially nilptr.go (read the source),
rotateN.go consume a lot of memory to compile, this is issue 1860 (and
probably others).

FWIW, Go will still work fine even with these failures, and I have
heard that compiler/linker memory usage is in rsc and dmitry's radar
for 1.3.

[minux]

On Fri, Sep 20, 2013 at 5:57 PM, ajstarks <ajst...@gmail.com> wrote:

FYI, this release builds on the original 256MB Raspberry PI,

glad to learn that Go still builds on the original Pi! 

but the tests fail with nilptr.go, rotate[1-3].go, fixedbugs/issue5162.go throwing incorrect output and out of memory errors.

the nilptr.go will throw out of memory panic, that's expected.

for the rotate tests, you can cross compile it on PC and copy and run the resulting binary program on the Pi, they should finish quickly and quietly

without using much memory (i.e. only the compiling phase requires a lot of memory)

fixedbugs/issue5162.go will generate a 16137 lines Go program as output, compiling that will require a large memory, you can cross compile

the generated source and run it on the Pi.

btw, thanks for testing the new rc.

[tho...@habets.se]

On Friday, 20 September 2013 05:07:21 UTC+1, Andrew Gerrand wrote:

Please help us by testing your Go programs with the new tool chain and libraries, and report any problems using the issue tracker:
    http://golang.org/issue/new

Do you want documentation issues there too?

Specifically:

* The tls module says it's a partial implementation of TLS 1.1, but the release notes say TLS 1.2. (and it kinda looks like the latter is right)

* What's "partial" about it? I'm guessing that it doesn't implement crap ciphers, but what else?

 

[minux]

On Sep 21, 2013 6:59 AM, <tho...@habets.se> wrote:
>
> On Friday, 20 September 2013 05:07:21 UTC+1, Andrew Gerrand wrote:
>>
>> Please help us by testing your Go programs with the new tool chain and libraries, and report any problems using the issue tracker:
>>     http://golang.org/issue/new
> Do you want documentation issues there too?

definitely. please file issues also for doc problems.

[Andrew Gerrand]

On 20 September 2013 14:30, Dan Kortschak <dan.ko...@adelaide.edu.au> wrote:

Yes, I saw those when they went in. So it's an untagged rc?

Correct. "Beta" might be a more apt name, but we decided with the shortened release cycle to issue the first release candidate as early as possible.

A policy set by the dist tool prevents us from tagging the release (as minux pointed out). We might revisit that policy at some point. Sorry for the inconvenience there.

Andrew

[Andrew Gerrand]

On 21 September 2013 05:11, Keith Rarick <k...@xph.us> wrote:

I'm curious about the "-osx10.8" naming convention for the darwin builds.
I assume a change like this would not be made gratuitously.

The Heroku buildpack makes a halfhearted attempt to work on multiple OSes.
https://github.com/kr/heroku-buildpack-go/blob/7ce7f7d/bin/compile#L10

Is there a rule I can follow to reliably assemble a URL for both linux
and darwin?

It's annoying that we need to provide binaries for different MacOS versions.

After I rolled the binaries I realized that "-macos10.8" might be a better naming convention ("osx10.8" expands to "oh ess ten ten point 8"), and will likely do that in future.

As for reliably detecting the OS X version, you can use "uname -r". Note that the version numbers are not "10.X" but some other scheme. See how the dist tool does it here: http://tip.golang.org/src/cmd/dist/unix.c#L709

Andrew

[Dan Kortschak]

On Mon, 2013-09-23 at 09:22 +1000, Andrew Gerrand wrote:
> Correct. "Beta" might be a more apt name, but we decided with the
> shortened release cycle to issue the first release candidate as early
> as possible.
>
> A policy set by the dist tool prevents us from tagging the release (as
> minux pointed out). We might revisit that policy at some point. Sorry
> for the inconvenience there.

No worries. Please see https://codereview.appspot.com/13500047/ for a
fix for this.

Dan

[Arne Hormann]

I think osx10.8 is fine. Apple doesn't seem to care for the redundancy, if you click about on a mac it also reports "OS X Version X.Y.Z".

[Andrew Gerrand]

On 23 September 2013 12:29, Arne Hormann <arneh...@gmail.com> wrote:

I think osx10.8 is fine. Apple doesn't seem to care for the redundancy, if you click about on a mac it also reports "OS X Version X.Y.Z".

Yeah, this has been pointed out by others, too. And I guess the term "MacOS" has fallen out of common use by now.

Andrew

[Arne Hormann]

It's also pretty unlikely that Apple will do an OS XI anytime soon, I think OS X is a brand and the meaning of X as a roman numeral is more or less lost.

[Kyle Lemons]

The way things are going now (new ipad, new nexus 7) we're lucky if the next set of operating systems aren't "New OS" and "New Windows" :).

On a more serious note, though, I've been running on the release candidate and haven't seen anything except the failure of that silly pprof test, and only on my single-core VM.

--- FAIL: TestCPUProfileMultithreaded (1.34 seconds)

        pprof_test.go:128: crc32.ChecksumIEEE: 0

        pprof_test.go:128: crc32.Update: 66

        pprof_test.go:138: crc32.ChecksumIEEE has 0 samples out of 66, want at least 11, ideally 33

FAIL

FAIL    runtime/pprof   4.174s

alas, I haven't had time to find a linux machine I can reboot into non-SMP to try if that also happens on non-virtualized hardware.

--