go1.1 build tags

[Brad Fitzpatrick]

Changing the subject.  No longer talking about assemblers.

On Wed, Sep 19, 2012 at 9:26 AM, minux <minu...@gmail.com> wrote:

On Thu, Sep 20, 2012 at 12:11 AM, Brad Fitzpatrick <brad...@golang.org> wrote:

On Wed, Sep 19, 2012 at 8:49 AM, minux <minu...@gmail.com> wrote:

On Wednesday, September 19, 2012, Brad Fitzpatrick wrote: 

I think we should make +build tags work in *.s files, though, so people can write assembly-having packages which work with both Go 1.0 and Go 1.1 using +build version tags.  (but that might just work already) 

I think build tag is already honored in assembly files.

Do you propose we automatically recognize go1 and go1.1 build tag?

Yes.  Maybe not those exact strings, but something similar.

On a second thought, i think cmd/go already do this.

it will automatically checkout go1 tag/branch if available, if go 1.1 is out, we can just

extend that to go1.1. This might be better than version build tags.

That's not what I'm proposing.  And honestly, nobody did a good job at maintaining their tags before Go 1.  I don't expect anybody to do a good job at branch management for their packages after Go 1.  A +build tag is much easier to maintain and for others to visually debug.

[minux]

my main reason against automatic version build tags is that it seems to contradict with

our Go 1 compatibility contract, and gives people the illusion that Go 1 is changing in

whatever ways such that version build tag is necessary.

limiting version build tags to assembly file might fix that problem, but it will introduce

inconsistency into the system.

[Brad Fitzpatrick]

On Wed, Sep 19, 2012 at 9:43 AM, minux <minu...@gmail.com> wrote:

On Thu, Sep 20, 2012 at 12:30 AM, Brad Fitzpatrick <brad...@golang.org> wrote:

On Wed, Sep 19, 2012 at 9:26 AM, minux <minu...@gmail.com> wrote:

On a second thought, i think cmd/go already do this.

it will automatically checkout go1 tag/branch if available, if go 1.1 is out, we can just

extend that to go1.1. This might be better than version build tags.

That's not what I'm proposing.  And honestly, nobody did a good job at maintaining their tags before Go 1.  I don't expect anybody to do a good job at branch management for their packages after Go 1.  A +build tag is much easier to maintain and for others to visually debug.

my main reason against automatic version build tags is that it seems to contradict with

our Go 1 compatibility contract, and gives people the illusion that Go 1 is changing in

whatever ways such that version build tag is necessary.

Go 1 is not changing.  Go 1.1 is growing.

Here's my concern, illustrated with a fake but very plausible example:

* Go 1.1 adds some net/http function

* One of these http helper packages like Gorilla thinks it's neat and want to use it.

* Oh, crap, that means Gorilla (a popular package) no longer works with Go 1.0, and the community is fragmented.

* Gorilla didn't really need that feature.  It was just optional.  They could've done it a different less elegant way or returned an error or whatnot.

A build tag would let people use new features if available, but still compile for Go 1.0.

[Dave Cheney]

> * Oh, crap, that means Gorilla (a popular package) no longer works with Go
> 1.0, and the community is fragmented.

The go1 contract says that it is always safe to compile code written
against 1.0 with 1.1 (or newer), therefore all users can and should
use the latest stable version. As I interpret the contract, the best
version of Go1 is always the latest stable version.

Cheers

Dave

[Brad Fitzpatrick]

Anybody on this list is not who I'm concerned about.

I'm concerned about "apt-get install golang" users.

[minux]

On Thu, Sep 20, 2012 at 12:48 AM, Brad Fitzpatrick <brad...@golang.org> wrote:

On Wed, Sep 19, 2012 at 9:43 AM, minux <minu...@gmail.com> wrote:

my main reason against automatic version build tags is that it seems to contradict with

our Go 1 compatibility contract, and gives people the illusion that Go 1 is changing in

whatever ways such that version build tag is necessary.

Here's my concern, illustrated with a fake but very plausible example:

* Go 1.1 adds some net/http function

* One of these http helper packages like Gorilla thinks it's neat and want to use it.

* Oh, crap, that means Gorilla (a popular package) no longer works with Go 1.0, and the community is fragmented.

* Gorilla didn't really need that feature.  It was just optional.  They could've done it a different less elegant way or returned an error or whatnot.

A build tag would let people use new features if available, but still compile for Go 1.0.

isn't this be better solved with branches?

[Brad Fitzpatrick]

I suspect the community has more hackers than release engineers.

 

[Andrew Gerrand]

This is also my concern, and I'm inclined to agree.

The worst case with the 1.1 build tag seems better than the worst case
without it.

Andrew

[Russ Cox]

I created issue 4116 for this.