<p>It Just Works. It was <em>actually</em> a painless upgrade. I installed it, killed the daemon I was developing. <code>go build</code> with the new version. Run it. Works. Back in the game. Downtime of under a minute. Fabulous. Good Job, Go Team. Go Go Team!</p>
<hr/>**评论：**<br/><br/>JHunz: <pre><p>It's actually the first version since 1.2.1 that didn't have some dealbreaker bug preventing us from upgrading the version we use to build our app. We were very excited to finally get to upgrade.</p></pre>rjc2013: <pre><p>Just out of curiosity: what were the dealbreakers? Did those Go versions violate the backwards-compatibility promise of Go 1?</p></pre>JHunz: <pre><p>No, the backwards compatibility was theoretically fine, there was nothing wrong with the API. It was just sort of niche bugs that happened to impact our app in a negative enough way that we couldn't ship with them. </p>
<p>I don't remember what all of them were. Go 1.4 in particular was a garbage collection bug involving CGO and uint16 pointers that caused an intermittent unrecoverable panic. Something that wouldn't affect most people but was totally a no-go for us.</p></pre>icholy: <pre><p>"no-go" lol</p></pre>JHunz: <pre><p>Wow, I'm a big fan of horrible puns, but that one was totally not intended!</p></pre>gogolang: <pre><p>I had issues when upgrading from 1.2.1 to 1.3, so I've held off on upgrading until I have some time to do thorough testing.</p>
<p>It turns out my original code had a bug in it that was actually producing the output that I expected (given my assumption about how bufio.Read worked). Some underlying change in implementation in 1.3 caused my code to break but it was expected behavior for bufio.Read... it just so happened that I had used it incorrectly.</p></pre>flavasava: <pre><p>I think we'd expect nothing less for a non-beta release ;)</p></pre>randonymous: <pre><p>Is there an upgrade guide somewhere?</p>
<p>It's not obvious what the intended upgrade path is, or what actually gets overwritten during upgrade.</p></pre>FIuffyRabbit: <pre><p>Delete your $GOPATH/pkg and delete the files/folders in $GOROOT and extract. It's that simple. </p></pre>aacanakin: <pre><p>in my code base, relative imports seem to be breaking, but it was a small project, therefore I changed relative imports to absolute imports and it is working seamless.</p></pre>xienze: <pre><p>To play devil's advocate here, your definition of "works" is "it compiles and doesn't crap out when I start it".</p></pre>brianolson: <pre><p>Okay, well then, to expand, I noticed now (a couple weeks later?) that it had been such a smooth transition and I never did have any trouble with it.</p></pre>voltaic_spear: <pre><p>Check golang-nuts and the issue tracker and you might revise your opinion.</p></pre>dmikalova: <pre><p>On the slack channel there's been a lot of commotion on how the new vendoring features break certain types of workflows :/</p></pre>THUNDERGROOVE: <pre><p>What's there to break? It's not like it on by default. If you use it and it breaks something of yours you were the one who tried it out.</p></pre>dmikalova: <pre><p>Yeah but if you now use godeps with the vendor folder it'll break testing or compilation. It's not a big deal, and yeah it's beta, but it doesn't just work.</p></pre>THUNDERGROOVE: <pre><p>I haven't really bothered with any build tools. I'm sure they're all nice, I just either stay away from projects that make breaking changes or vendor stuff myself and live with horrible import paths. I rarely have to use stuff outside of the standard libraries and experimental libraries.</p></pre>slimsag: <pre><p>AFAIK That feature is experimental, though. So there should be such discussion.</p></pre>dmikalova: <pre><p>Yes, definitely!</p></pre>
