aboutsummaryrefslogtreecommitdiff
path: root/_content/doc/modules/developing.md
diff options
context:
space:
mode:
authorSteve Traut <straut@google.com>2021-03-01 10:42:43 -0500
committerSteve Traut <straut@google.com>2021-03-02 21:51:57 +0000
commit02ef8fa5ddb8111aa8752ffb8267e67c4e209649 (patch)
tree13085d9e3c6b067ff0aa923aabcd93c5dc7975b3 /_content/doc/modules/developing.md
parent65c83740113547629052d38de46b57b708ec6e2b (diff)
downloadgo-x-website-02ef8fa5ddb8111aa8752ffb8267e67c4e209649.tar.xz
_content/doc: fix module and tutorial bugs and clean up flow
For golang/go#44241 - Fix issues 2, 3, 8, 16, 17, 18 from golang/go#44241 Other changes in multiple topics: - In markdown, replace HTML anchor tags with {#anchor} tags. - In a few places, add content to clarify that module path must be a location from which the module can be downloaded. - Where it was missing, add example.com domain to example module paths. Hopefully, this will reinforce the idea that the module path should typically include a domain. Docs will use something that looks like a domain name for module path. - Add more cross-references from tutorial to references for packages and commands. - Rewrite a few links so that they include the topic title, rather than simply inline text. Left those links whose destinations are references -- the item's name seems to suggest that a reference is at the destination. - Remove domain name from golang.org doc links, leaving root directory. Such as /cmd/go/* or /doc/modules/* - Add path up to root for all links in the same domain. Some were linking by file name only. - Change standard library links from golang.org to pkg.go.dev. Changes in the module tutorial: - Add text to help clarify that there should be a hello and greetings directory as siblings in their directory hierarchy. Some users thought one should be subordinate to the other. - Where needed, reorder steps so that `go mod init` is run before code is added. This is intended to reinforce the importance of the module's presence. - In require/replace steps, have the user use `go mod edit` rather than editing the go.mod file in an editor. The tools are more likely to yield a functioning result. - Where possible/appropriate, change module directive link destinations from "Modules reference" to go.mod reference. - Change "run the code" steps so that they all use `go run .` rather than `go build` or `go run <filename>`. This removes the impedance of explanation and more commands, while moving the explanation of `go build` and `go install` to a separate topic where they share a clearer context. - Add a "Conclusion" topic with a few links. The tutorial ended rather abruptly before. - Minor edits to remove some redundant language. Change-Id: I93055035d73c362ba73edea458fc53bc45e66512 Reviewed-on: https://go-review.googlesource.com/c/website/+/297531 Trust: Steve Traut <straut@google.com> Run-TryBot: Steve Traut <straut@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Diffstat (limited to '_content/doc/modules/developing.md')
-rw-r--r--_content/doc/modules/developing.md23
1 files changed, 9 insertions, 14 deletions
diff --git a/_content/doc/modules/developing.md b/_content/doc/modules/developing.md
index bcaabfe8..c1cbe4cd 100644
--- a/_content/doc/modules/developing.md
+++ b/_content/doc/modules/developing.md
@@ -25,7 +25,7 @@ To support developing, publishing, and using modules, you use:
[Versioning](#versioning).
* **Go tools** that make it easier for other developers to manage
dependencies, including getting your module's source, upgrading, and so on.
- See [Managing dependencies](managing-dependencies).
+ See [Managing dependencies](/doc/modules/managing-dependencies).
**See also**
@@ -33,10 +33,9 @@ To support developing, publishing, and using modules, you use:
isn't the topic for you. Instead, see [Managing
dependencies](managing-dependencies).
* For a tutorial that includes a few module development basics, see
- [Tutorial: Create a Go module](https://golang.org/doc/tutorial/create-module).
+ [Tutorial: Create a Go module](/doc/tutorial/create-module).
-<a id="workflow" ></a>
-## Workflow for developing and publishing modules
+## Workflow for developing and publishing modules {#workflow}
When you want to publish your modules for others, you adopt a few conventions to
make using those modules easier.
@@ -51,8 +50,7 @@ and versioning workflow](release-workflow).
1. Over time, revise the module with versions that use a version numbering
convention that signals each version's stability and backward compatibility.
-<a id="design" ></a>
-## Design and development
+## Design and development {#design}
Your module will be easier for developers to find and use if the functions and
packages in it form a coherent whole. When you're designing a module's public
@@ -70,8 +68,7 @@ functions in the module while the module is still in development. For more
information, see "Coding against an unpublished module" in [Module release and
versioning workflow](release-workflow#unpublished).
-<a id="decentralized" ></a>
-## Decentralized publishing
+## Decentralized publishing {#decentralized}
In Go, you publish your module by tagging its code in your repository to make it
available for other developers to use. You don't need to push your module to a
@@ -88,13 +85,12 @@ along with the module version number you use to tag the module for release, to
locate and download the module for its users.
For more about source and publishing conventions and best practices, see
-[Managing module source](managing-source).
+[Managing module source](/doc/modules/managing-source).
For step-by-step instructions on publishing a module, see [Publishing a
module](publishing).
-<a id="discovery" ></a>
-## Package discovery
+## Package discovery {#discovery}
After you've published your module and someone has fetched it with Go tools, it
will become visible on the Go package discovery site at
@@ -107,8 +103,7 @@ runs the `go get` command to download its source code to compile with.
For more about how developers find and use modules, see [Managing
dependencies](managing-dependencies).
-<a id="versioning" ></a>
-## Versioning
+## Versioning {#versioning}
As you revise and improve your module over time, you assign version numbers
(based on the semantic versioning model) designed to signal each version's
@@ -121,4 +116,4 @@ For more on developing major version updates, see [Developing a major version
update](major-version).
For more about how you use the semantic versioning model for Go modules, see
-[Module version numbering](version-numbers).
+[Module version numbering](/doc/modules/version-numbers).