Comment 1:

We should perhaps discuss whether we indeed *do* want to do something. I would favour
not doing anything except making it as easy as possible to get people moving onto go1.1
because otherwise we just end up with a fragmented community.
But this probably isn't the right forum to hash that out.

Comment 2:

We have to do something: either provide support for identifying go 1.1
builds or remove all the API changes.

Comment 3:

relevant discussion on golang-dev:
https://groups.google.com/group/golang-dev/browse_thread/thread/d694f4cf7b1c1c3d/47541e78b503f922

Comment 4:

Brad and I were discussing this just a day or so ago. Here's my take on why there's
little point on having a build tag for Go 1.1.
(a) it's only relevant to packages that are using Go 1.1 features (e.g. the new "html"
package)
(b) if such packages can provide a useful substitute without that new feature then
there's no point using it; they may as well just use the substitute for everyone
(c) given (a) and (b), a go1.1 build tag would only be useful to packages that, say,
offer an expanded API that would use Go 1.1 features, thus meaning that that package has
a non-uniform API. But then what would programs do that use that package? They can't use
those new features without restricting themselves to Go 1.1, at which point the build
tag doesn't buy them anything.
The "Debian problem" (people stuck on old distros that only give them Go 1.0.x) is not,
in my opinion, a problem. Such people can still build Go from source. If they are truly
stuck in a conservative situation where they can't upgrade Go, they probably should not
be upgrading Go libraries either.
I've been trying to come up with a worked example of where a go1.1 build tag would
actually be useful, but can't come up with a scenario that makes sense. Perhaps someone
can enlighten me and describe such a scenario.

Comment 5:

In theory it shouldn't be necessary, but in practice it is. The build
tag is all about pragmatism. We have gc and gccgo build tags too, even
though in theory that shouldn't be necessary either.
The question in my mind is what the form of the tag should be. I think
that using 'go1.1' to mean 'go1.1 or later' works well.
Russ

Comment 6:

one use case would be for performance.
suppose Go 1.1 introduce a new efficient way to doing something, so some package
might provide two version: one slower version for Go 1.0.x and one faster for Go 1.1+.

Comment 7:

Go 1.1 will have 99.9% compatibility with Go 1.0 so the idea of providing a 1.0
compatible package that doesn't use some 1.1 improvements sounds odd. I certainly would
like to see every Go user switch to 1.1 the day it ships. My concern is this tag may
encourage users to not upgrade to 1.1 when it ships and instead waste time developing
elaborate backport packages.
This is not to say there is not a package/api versioning problem on the horizon. This
tag is one facet of it, the debian/distro problem is another, but I worry that a go1.1
tag sets a precident for the go 1.2 tag, or worse, the go 1.1.2 tag.

Comment 8:

I'm all for pragmatism, but I can't see the gain here, only downside.
Perhaps you can spell out a situation where it would be useful?

Comment 9:

There is new API in Go 1.1. Suppose someone wants to use it in one of
their packages but also arrange for the code to compile under Go
1.0.x. They can write separate versions of the functionality, one
tagged with go1.1 and one tagged with !go1.1 (presumably that one
would return an error or something like that), the same way we do for
existing operating system differences (linux vs darwin), compiler
differences (gccgo vs gc) or context differences (appengine vs not).
I hope this will be the replacement for the version control branch tag
stuff, which I removed just before Go 1 and really wasn't working
well. Compared to that approach, I see two important benefits:
1. There is just one official version of the code. You can make a tar
file of source that builds everywhere, for example, without version
control issues getting mixed in.
2. The version control tags were '<=': marking code as 'r57' meant
that the code would not get used for r58, which meant each new
released required more tags. The build tags are (at least as
envisioned) '>='. Any release after go1.1 will satisfy the go1.1 tag,
so that if you need a feature from Go 1.1 but that's all, you tag the
code go1.1 and it keeps getting used for Go 1.2, Go 2, and so on.
You asked earlier about whether there would be calls for 3-level tags
like go1.0.4. I think we can say no: we've adopted the convention that
those releases are bug fixes only, with zero API differences, so that
it is trivial to move between them. It is only the +.1 releases that
add new API, so those should be the only ones that need adjustments to
what the compiler is asked to build.
Russ

Comment 10:

The difference to those other contexts is that those ones all have
actual realistic implementation alternatives: linux vs. darwin might
mean just different syscalls or whatever, gccgo vs. gc means symbol
information, appengine vs. !appengine means using unsafe or doing it
slower. In each alternative it is usually understood that the
functionality is generally there, just in a different form. That's not
true in the go1.1 scenario.
The use case here is also fairly niche. We are doing it for:
  - a programmer using Debian (or similar) with only go1.0.x
  - who is not able/willing to install go1.1 via distro, PPA or from source
  - who nonetheless wants to upgrade a package they use that wants to
start using a go1.1 feature, but doesn't want to use that feature
  - who is not able/willing to wind that package back to a pre-go1.1
state, nor fork it themselves
  - who is able to convince the package owner to support the go1.1 tag
and provide dummy version of all parts of their package's API that use
the go1.1 feature
That's a lot of caveats for a niche when there are a good half dozen
or so workarounds.

Comment 11:

Don't you also need +build tags to do assembly that works with both Go 1.0 and Go 1.1,
if ints are now sometimes bigger?

Comment 12:

If you're doing assembly then you know the native size of an int.
amd64 -> 8 bytes, 386 -> 4 bytes, etc. I don't think we support any
kind of portable assembly.

Comment 13:

> If you're doing assembly then you know the native size of an int.
That's not what I'm saying, David.  I think you know what I'm saying but you're arguing
just to argue at this point.

Comment 14:

I'm really not, but I did misunderstand you.
amd64 has 4 byte ints in go1.0, but 8 byte ints in go1.1. That could
indeed be handled by a +build tag, but it could also be handled just
by not using "int" in the Go -> asm interface. Unless people write the
public interface in asm, in which case they could write a trivial Go
func that calls an unexported asm, casting to int64.

Comment 15:

This issue now lists many situations where the go1.1 tag might be
important. Yes, they should be rare, but any use of +build tags should
be rare. The argument against the build tag is to avoid fragmentation,
but the build tag is not the cause of the fragmentation. API additions
or other changes are what cause fragmentation. The build tag provides
a way for conscientious Go developers to keep people using older
versions of Go happy.
There is a claim here that the only people using Go 1.0 are Debian
users. I don't think that's true at all. During a transition period
following the initial release of Go 1.1 there will be people who want
time to evaluate Go 1.1 in their own production environments before
making the switch, and it would be good to provide a way for authors
of third-party libraries to keep their code Go 1.0-compatible during
that transition. I expect that a thorough customer might wait as long
as six to twelve months before switching, depending on how well Go 1.1
works and how many point releases it takes to correct whatever tricky
corner cases they run into.
I agree completely with the ideal of not needing a go1.1 tag. But I
think the situation is not ideal, and so we need it.

Comment 16:

Labels changed: added size-m.

Comment 17:

This issue was closed by revision e778f93.

Status changed to Fixed.