I don't think they've given up on the idea considering there still is no official version management.
Sorry, that wasn't clear, I was talking about the language itself - the language is now versioned, but it wasn't for initial releases - they had weekly snapshots, then moved to formal versioning and gave up on the idea of being version-less. See these slides about version 1:
What holds for the language holds also for libraries I think - having explicit versioned releases and being able to sometimes break backwards compatibility is really useful, esp. if others can pin whatever version they import easily and migrate at their own pace.
I think it's good people are experimenting with pkg versioning - if someone comes up with an elegant solution and deals with most of the edge cases, it'll probably get into the bundled tools like go get eventually, or people will stop using go get and use another better tool. go get is not essential for fetching go libraries, it's just the blessed method.
Sorry, that wasn't clear, I was talking about the language itself - the language is now versioned, but it wasn't for initial releases - they had weekly snapshots, then moved to formal versioning and gave up on the idea of being version-less. See these slides about version 1:
http://talks.golang.org/2012/go1.slide
What holds for the language holds also for libraries I think - having explicit versioned releases and being able to sometimes break backwards compatibility is really useful, esp. if others can pin whatever version they import easily and migrate at their own pace.
I think it's good people are experimenting with pkg versioning - if someone comes up with an elegant solution and deals with most of the edge cases, it'll probably get into the bundled tools like go get eventually, or people will stop using go get and use another better tool. go get is not essential for fetching go libraries, it's just the blessed method.