Change "Goinstall" to "go get"; this is long overdue. Remove some info about Go <1.

PackagePublishing.md

@@ -1,5 +1,5 @@
 # Introduction
-Now that you've spent many hours writing your package and debugging it and testing it (you did [[test it|TableDrivenTests]], didn't you?), you want to publish it so other people can [go install](http://golang.org/cmd/go/) your package and see it on the [dashboard](https://godoc.org/).
+Now that you've spent many hours writing your package and debugging it and testing it (you did [[test it|TableDrivenTests]], didn't you?), you want to publish it so other people can [go get](http://golang.org/cmd/go/) your package and see it on the [dashboard](https://godoc.org/).
 
 First, you will need to host it online somewhere.  Four major code hosting sites are [bitbucket](http://bitbucket.org/) (hg/git), [GitHub](http://github.com/) (git), [googlecode](http://code.google.com/projecthosting/) (hg/git/svn), and [launchpad](http://launchpad.net) (bzr).  I recommend choosing whichever version control system you are familiar with or which your code is versioned locally on your machine.  Git (git) is the version control system used by the central Go repository, so it is the closest to a guarantee as you can get that a developer wanting to use your project will have the right software. If you have never used version control before, these websites have some nice HOWTOs and you can find many great tutorials by searching Google for "{name} tutorial" where {name} is the name of the version control system you would like to learn.
 
@@ -15,7 +15,7 @@ import "github.com/kylelemons/go-gypsy/yaml"
              `----------------------------- Hosting site
 ```
 
-As of the time of this writing, the current release (r60 (on Google Code)) does support subdirectories of package repositories, but if you are going to be supporting earlier versions, note that they may not have a go install binary which reports subdirectories within a repository to the dashboard.
+Go >= version 1 supports subdirectories of package repositories.
 
 ## Subdirectories
 
@@ -34,18 +34,18 @@ The import statement for the package would look like:
 import "codesite.tld/authorName/Go-PublishingExample/epub"
 ```
 
-It is often a good idea to make sure the last directory path (in this case, "epub") matches the name of the package used by the source files in the directory.  In this case, no goinstallable files were included in the base directory because neither the binary nor the package were to be named "Go-PublishingExample".
+It is often a good idea to make sure the last directory path (in this case, "epub") matches the name of the package used by the source files in the directory.  In this case, no go get-able files were included in the base directory because neither the binary nor the package were to be named "Go-PublishingExample".
 
 ## Branches and Tags
 In general, the Go source tree can exist in three basic states.  It can be checked out at a Go Release branch (r60 (on Google Code) at the time of this writing -- this is where most users should be), or it can be checked out at a Go Weekly (a new tag for which is made roughly once per week), or at tip (the Mercurial term for the latest change).  The last two are primarily for developers of the Go language itself or developers who need features or fixes which have not been introduced into the latest Release.
 
-Due to the lielihood that you might continue collaborating on your project with your team on code that is not ready for general consumption, it is recommended that you utilize the tagging or branching functionality of your version control system.  The goinstall tool understands some special tags and branches, which you may want to use to ensure users get a compatible version of your package:
+Due to the lielihood that you might continue collaborating on your project with your team on code that is not ready for general consumption, it is recommended that you utilize the tagging or branching functionality of your version control system.  The go get tool understands some special tags and branches, which you may want to use to ensure users get a compatible version of your package:
 ```
   go.r60               -- A "go.r##" tag will be checked out if the user has that Go release installed
   go.weekly.2011-07-19 -- A "go.weekly.YYYY-MM-DD" tag will be checked out if the user has that weekly installed
 ```
 
-Goinstall will attempt to fall back to the previous tag if the installed one has no matches, and if none are found, will default to installing tip.
+Go get will attempt to fall back to the previous tag if the installed one has no matches, and if none are found, will default to installing tip.
 
 To create and maintain your release tag in mercurial:
 ```
@@ -71,11 +71,11 @@ If you are using other branch names, substitute those names where necessary.
 It will typically not be necessary to maintain weekly tags or branches, but it can be very useful to maintain the release branch or tag, as this will ensure the widest audience for your project.
 
 ## Commands vs Packages
-Since goinstall does not use your project's Makefiles, it is important to understand how it will actually build your project.
+Since go get does not use your project's Makefiles, it is important to understand how it will actually build your project.
 
-All files in the same directory should always share the same package name.  Any files named with a ` _test ` or an ` _os ` and/or ` _arch ` suffix will be ignored (unless the os/arch match).  If the package name is "main", goinstall will build an executable from the source files and name it according to the directory name (using the last path segment only).  If the package name is anything else, goinstall will build it as a package and the import path will be the web-accessible URL for your project's root followed by the subdirectory.  See [the goisntall documentation](http://golang.org/cmd/goinstall) for how to make import paths for code hosting sites other than the main four.
+All files in the same directory should always share the same package name.  Any files named with a ` _test ` or an ` _os ` and/or ` _arch ` suffix will be ignored (unless the os/arch match).  If the package name is "main", go get will build an executable from the source files and name it according to the directory name (using the last path segment only).  If the package name is anything else, go get will build it as a package and the import path will be the web-accessible URL for your project's root followed by the subdirectory.  See [the go get documentation](http://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies) for how to make import paths for code hosting sites other than the main four.
 
-Dependencies between packages in the same project are common.  In the case where one package or command in your project depends upon another, you must use the full import path in order for goinstall to recognize the dependency and make sure it is built.  Third-party packages which are imported from source files in your project will also be automatically downloaded and installed by goinstall if it is not already present.
+Dependencies between packages in the same project are common.  In the case where one package or command in your project depends upon another, you must use the full import path in order for go get to recognize the dependency and make sure it is built.  Third-party packages which are imported from source files in your project will also be automatically downloaded and installed by go get if it is not already present.
 
 To reuse the example above, the file ` ./publish/main.go ` may look something like this:
 ```
@@ -97,11 +97,11 @@ func main() {
 
 A user wishing to install this executable would execute:
 ```
-goinstall codesite.tld/authorName/Go-PublishingExample/publish
+go get codesite.tld/authorName/Go-PublishingExample/publish
 ```
 which would also install the ` ".../epub" ` package because of the dependency.  A developer simply wishing to install the library could execute:
 ```
-goinstall codesite.tld/authorName/Go-PublishingExample/epub
+go get codesite.tld/authorName/Go-PublishingExample/epub
 ```
 and (if he had not already installed ` publish `) would only download and install the package.  Note that in none of these cases are the examples or documentation downloaded; in most cases these would be available to browse via the code site.