go1.1.2 is released

[Andrew Gerrand]

Hi,

We've just released Go version 1.1.2.

It includes several fixes to the compiler and runtime.

See the change history for details:
    http://golang.org/s/go1.1.2-changes

You can download binary and source distributions from the usual place:
    https://code.google.com/p/go/downloads/list

To compile from source, update to the release with "hg update release" and build as usual.

Thanks to everyone who contributed to the release.

Andrew

[yxtiger]

Congratulation!

[Keith Rarick]

Congrats, everyone. :)

I just updated the Go Heroku buildpack to use version 1.1.2.
As a reminder, it's at:
https://github.com/kr/heroku-buildpack-go

Thanks for this release!

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

[Peter Kleiweg]

Op dinsdag 13 augustus 2013 08:48:34 UTC+2 schreef Andrew Gerrand:

Hi,

We've just released Go version 1.1.2.

After upgrading Go, do I need to reinstall the packages I have added in GOPATH? 

[Jan Mercl]

On Tue, Aug 13, 2013 at 10:42 AM, Peter Kleiweg <pkle...@xs4all.nl> wrote:
> After upgrading Go, do I need to reinstall the packages I have added in
> GOPATH?

No. However, sometimes I cannot help myself and I do 'rm -rf
$GOPATH/pkg' with a new release (like today). Nothing rational behind
it ;-)

-j

[Peter Kleiweg]

Op dinsdag 13 augustus 2013 10:42:00 UTC+2 schreef Peter Kleiweg:

It seems  I do. I couldn't use a package that uses cgo until I reinstalled.

[Jan Mercl]

On Tue, Aug 13, 2013 at 12:16 PM, Peter Kleiweg <pkle...@xs4all.nl> wrote:
> It seems I do. I couldn't use a package that uses cgo until I reinstalled.

Then please check if such bug is already reported and if not, please
fill in issue with a minimal repro case.

Or I must be completely mistaken about the Go build system being able
to properly figure out when and what has to be rebuild automatically.

-j

[Peter Kleiweg]

Op dinsdag 13 augustus 2013 12:20:51 UTC+2 schreef Jan Mercl:

If Go tried to reinstall the package, that explains why it didn't work. I need to set an environment variable before I can install that particular package. 

[Thomas Bushnell, BSG]

Congratulations!

On Mon, Aug 12, 2013 at 11:48 PM, Andrew Gerrand <a...@golang.org> wrote:

--

[Ross Salas]

Congrats!

[AndrewN]

Nice. Had a minor issue with the MacOS 64bit package installer. Failed with "The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance." The install log (see System Information") showed the real problem was that the Xcode license hadn't been signed (caught in the Apple developer downtime). A 'sudo xcodebuild -license" in a terminal takes care of that now that Apple dev is back.

[Michael Banzon]

+1 to the OSX issue.

The installation is working fine though...

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



--

Michael Banzon
http://michaelbanzon.com/

[Uli Kunitz]

It's a pity that the fix for the godoc issue 5977 has not been included in 1.1.2. The patch consists of a one line change. The release branch still includes godoc so I would expect bugs for it to be fixed. 

it appears that godoc will not be part of the 1.2 release and the sources have already been moved to a special repository. Unfortunately the changeset doesn't provide a rationale for that decision. For people like me that are building from source the separate repository for godoc this change will mean an additional step to build a complete golang environment. The 1.2 documentation should have some words about the rationale and some short guidance for people building from source. This would make the inconvenience easier to bear. 

[Peter Kleiweg]

Op dinsdag 13 augustus 2013 21:36:44 UTC+2 schreef Uli Kunitz:

it appears that godoc will not be part of the 1.2 release 

Don't be silly. That wouldn't make any sense. 

[Brad Fitzpatrick]

We're not done with 1.2 yet.

Finishing the godoc transition and documentation will be part of that.

The rationale is that godoc is being split up into lots of pieces, isn't part of the Go 1 API contract, and will be increasingly depending on lots of go.tools stuff (like go/types).  It's easier to work with it in go.tools.

The downloads will still contain godoc.

On Tue, Aug 13, 2013 at 12:36 PM, Uli Kunitz <uli.k...@gmail.com> wrote:

It's a pity that the fix for the godoc issue 5977 has not been included in 1.1.2. The patch consists of a one line change. The release branch still includes godoc so I would expect bugs for it to be fixed. 

it appears that godoc will not be part of the 1.2 release and the sources have already been moved to a special repository. Unfortunately the changeset doesn't provide a rationale for that decision. For people like me that are building from source the separate repository for godoc this change will mean an additional step to build a complete golang environment. The 1.2 documentation should have some words about the rationale and some short guidance for people building from source. This would make the inconvenience easier to bear. 

--

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.

[Shivakumar GN]

At source level godoc has already moved out of golang sources to code.google.com/p/go.tools

But binary still gets installed into %GOROOT/bin and will likely continue to be part of binary distribution.

[Shivakumar GN]

Wasn't the initial idea to move go/types from non-core repo to go core repo once it matures?

Any reason why moving sub-items from go.tools into $GOROOT as and when they mature not a good idea?

[Andrew Gerrand]

On 14 August 2013 12:10, Shivakumar GN <shivak...@gmail.com> wrote:

Wasn't the initial idea to move go/types from non-core repo to go core repo once it matures?

Any reason why moving sub-items from go.tools into $GOROOT as and when they mature not a good idea?

We wanted to turn godoc into a library so we can re-use its code for documentation projects like tip.golang.org. It doesn't make sense for us to actively work on something in the core repo just to support some external users, so go.tools is a more convenient place to work from (you can go get godoc, now). For 99.9% of Go users this should be a non-issue.

Remember that anything we put in the core repo we must not change because of the compatibility promise. Until go/types is fully mature, it won't go in the core repo. The package will reach maturity through use, and one of its good use cases is in godoc. It's inconvenient for a command in the core repo to track a dependency from outside.

Andrew 

[Shivakumar GN]

Makes sense. godoc as a library is a fantastic idea. I had missed noticing its refactoring into go.tools/godoc and go.tools/cmd/godoc.

Thanks.