| <!--{ |
| "Title": "Developing and publishing modules" |
| }--> |
| |
| You can collect related packages into modules, then publish the modules for |
| other developers to use. This topic gives an overview of developing and |
| publishing modules. |
| |
| To support developing, publishing, and using modules, you use: |
| |
| * A **workflow** through which you develop and publish modules, revising them |
| with new versions over time. See [Workflow for developing and publishing |
| modules](#workflow). |
| * **Design practices** that help a module's users understand it and upgrade |
| to new versions in a stable way. See [Design and development](#design). |
| * A **decentralized system for publishing** modules and retrieving their code. |
| You make your module available for other developers to use from your own |
| repository and publish with a version number. See [Decentralized |
| publishing](#decentralized). |
| * A **package search engine** and documentation browser (pkg.go.dev) at which |
| developers can find your module. See [Package discovery](#discovery). |
| * A module **version numbering convention** to communicate expectations of |
| stability and backward compatibility to developers using your module. See |
| [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](/doc/modules/managing-dependencies). |
| |
| **See also** |
| |
| * If you're interested simply in using packages developed by others, this |
| 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](/doc/tutorial/create-module). |
| |
| ## 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. |
| |
| The following high-level steps are described in more detail in [Module release |
| and versioning workflow](release-workflow). |
| |
| 1. Design and code the packages that the module will include. |
| 1. Commit code to your repository using conventions that ensure it's available |
| to others via Go tools. |
| 1. Publish the module to make it discoverable by developers. |
| 1. Over time, revise the module with versions that use a version numbering |
| convention that signals each version's stability and backward compatibility. |
| |
| ## 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 |
| API, try to keep its functionality focused and discrete. |
| |
| Also, designing and developing your module with backward compatibility in mind |
| helps its users upgrade while minimizing churn to their own code. You can use |
| certain techniques in code to avoid releasing a version that breaks backward |
| compatibility. For more about those techniques, see [Keeping your modules |
| compatible](/blog/module-compatibility) on the Go blog. |
| |
| Before you publish a module, you can reference it on the local file system using |
| the replace directive. This makes it easier to write client code that calls |
| 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). |
| |
| ## 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 |
| centralized service because Go tools can download your module directly from your |
| repository (located using the module's path, which is a URL with the scheme |
| omitted) or from a proxy server. |
| |
| After importing your package in their code, developers use Go tools (including |
| the `go get` command) to download your module's code to compile with. To support |
| this model, you follow conventions and best practices that make it possible for |
| Go tools (on behalf of another developer) to retrieve your module's source from |
| your repository. For example, Go tools use the module's module path you specify, |
| 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](/doc/modules/managing-source). |
| |
| For step-by-step instructions on publishing a module, see [Publishing a |
| module](publishing). |
| |
| ## 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 |
| [pkg.go.dev](https://pkg.go.dev/). There, developers can search the site to find |
| it and read its documentation. |
| |
| To begin using the module, a developer imports packages from the module, then |
| 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). |
| |
| ## 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 |
| stability and backward compatibility. This helps developers using your module |
| determine when the module is stable and whether an upgrade may include |
| significant changes in behavior. You indicate a module's version number by |
| tagging the module's source in the repository with the number. |
| |
| 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](/doc/modules/version-numbers). |