On 17/03/15 16:28 -0400, Tim St Clair wrote:
We're going to have to eat the update at some point, is there a reason to hold off (other then churn)?
Golang holds itself to a forward compatibility. So if code was strictly written to go1.3, then it will compile and run fine on >= go1.4 I've made other updates to golang mid-stream of fedora releases. Like go1.2 -> go1.3, but that was largely just improvements. go1.3 -> go1.4 they axed a bunch of stuff from ./misc/ like emacs modes, vim support, etc. The existing packages for go1.3 won't line up. So fedora users that have them installed, would get a broken experience. It is something just intricate enough that I'm inclined to avoid where possible. vb
----- Original Message -----From: "Vincent Batts" <vbatts redhat com> To: atomic-devel projectatomic io, "Eric Paris" <eparis redhat com> Sent: Tuesday, March 17, 2015 12:50:13 PM Subject: [atomic-devel] go1.4 requirement I see that upstream etcd is now requiring go1.4 https://github.com/coreos/etcd/issues/2524 Docker has churned on this for a while, but I have staved them off since upgrading f20, f21 and epel6 to go1.4 would deprecate a few packages (bash completion, emacs and vim editor files, etc) and this is not something I care to push mid stream. The `net/http` BasicAuth is pretty small https://golang.org/src/net/http/request.go?s=16575:16641#L518 and seems like it _could_ be easily backported, though there are other nice improvements to move forward to go1.4 for. And I'm not keen on backporting things where an upgrade of version would be easier... Thoughts? vb-- Cheers, Timothy St. Clair Red Hat Inc.
Attachment:
pgpnMJzL76CRB.pgp
Description: PGP signature