From 026d4d24e88af30c6b1fbd005edaa0395eeb6ffc Mon Sep 17 00:00:00 2001
From: thepudds <20628140+thepudds@users.noreply.github.com>
Date: Mon, 3 Dec 2018 15:13:41 -0500
Subject: [PATCH] don't use 'foo' for a package name in 'Releasing Modules (v2
 or Higher)' section

---
 Modules.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Modules.md b/Modules.md
index 6cfccb24..a5531782 100644
--- a/Modules.md
+++ b/Modules.md
@@ -314,13 +314,13 @@ Note that if you adopting modules for the first time for a pre-existing reposito
 
 There are two ways to release a v2 or higher module. Using the example of creating a `v3.0.0` release, the two options are:
 
-1. **Major branch**: Update the `go.mod` file to include a `/v3` at the end of the module path in the `module` directive (e.g., `module github.com/my/module/v3`). Update import statements within the module to also use `/v3` (e.g., `import "github.com/my/module/v3/foo"`). Tag the release with `v3.0.0`. 
+1. **Major branch**: Update the `go.mod` file to include a `/v3` at the end of the module path in the `module` directive (e.g., `module github.com/my/module/v3`). Update import statements within the module to also use `/v3` (e.g., `import "github.com/my/module/v3/mypkg"`). Tag the release with `v3.0.0`. 
    * Go versions 1.9.7+, 1.10.3+, and 1.11 are able to properly consume and build a v2+ module created using this approach without requiring updates to consumer code that has not yet opted in to modules (as described in the the ["Semantic Import Versioning"](https://github.com/golang/go/wiki/Modules#semantic-import-versioning) section above). 
    * A community tool [github.com/marwan-at-work/mod](https://github.com/marwan-at-work/mod) helps automate this procedure. See the [repository](https://github.com/marwan-at-work/mod) or the [community tooling FAQ](https://github.com/golang/go/wiki/Modules#what-community-tooling-exists-for-working-with-modules) below for an overview.
    * To avoid confusion with this approach, consider putting the `v3.*.*` commits for the module on a separate v3 branch.
    * **Note:** creating a new branch is _not_ required. If instead you have been previously releasing on master and would prefer to tag `v3.0.0` on master, that is a viable option. (If you do decide to tag `v3.0.0` on master, you can consider creating a v2 branch for any future v2 bug fixes).
 
-2. **Major subdirectory**: Create a new `v3` subdirectory (e.g., `my/module/v3`) and place a new `go.mod` file in that subdirectory. The module path must end with `/v3`. Copy or move the code into the `v3` subdirectory. Update import statements within the module to also use `/v3` (e.g., `import "github.com/my/module/v3/foo"`). Tag the release with `v3.0.0`.
+2. **Major subdirectory**: Create a new `v3` subdirectory (e.g., `my/module/v3`) and place a new `go.mod` file in that subdirectory. The module path must end with `/v3`. Copy or move the code into the `v3` subdirectory. Update import statements within the module to also use `/v3` (e.g., `import "github.com/my/module/v3/mypkg"`). Tag the release with `v3.0.0`.
    * This provides greater backwards compatibility. In particular, Go versions older than 1.9.7 and 1.10.3 are also able to properly consume and build a v2+ module created using this approach.
 
 See https://research.swtch.com/vgo-module for a more in-depth discussion of these alternatives.