You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the new experimental vendor folder support coming in 1.5, and the rapid adoption of Dave Cheney's gb project, I've been thinking about how to make the Go newcomer experience better.
For example, if you are developing a program in Go, I'd argue that you should:
Make binary builds available on Mac, Linux, Win
Use semantic versioning to label those releases
Not ask users to download and install Go in order to build your program source
Not have to care about whether your program can be installed via go get
However, if you are creating a library in Go, then you really should:
Make sure that your library is go get-able
Your project should be listed/registered in godoc.org
Your top-level readme should include information about API stability, etc.
Do you think this distinction is important? If so, how best to communicate that to the developer and user communities?
The text was updated successfully, but these errors were encountered:
Another topic I'd like your opinion on...
With the new experimental vendor folder support coming in 1.5, and the rapid adoption of Dave Cheney's
gb
project, I've been thinking about how to make the Go newcomer experience better.For example, if you are developing a program in Go, I'd argue that you should:
go get
However, if you are creating a library in Go, then you really should:
go get
-ableDo you think this distinction is important? If so, how best to communicate that to the developer and user communities?
The text was updated successfully, but these errors were encountered: