The following sequence illustrates release and versioning workflow steps for an example new module. For more about each step, see the sections in this topic.
- **Begin a module and organize its sources** to make it easier for developers to use and for you to maintain.
If you're brand new to developing modules, check out Tutorial: Create a Go module.
In Go's decentralized module publishing system, how you organize your code matters. For more, see Managing module source.
- **Set up to write local client code that calls functions in the unpublished module.**
Before you publish a module, it's unavailable for the typical dependency management workflow using commands such as `go get`. A good way to test your module code at this stage is to try it while it is in a directory local to your calling code.
See Coding against an unpublished module for more about local development.
- **When the module's code is ready for other developers to try it out, begin publishing v0 pre-releases such as alphas and betas.** See Publishing pre-release versions for more.
- **Release a v0 that's not guaranteed to be stable, but which users can try out.** For more, see Publishing the first (unstable) version.
- **After your v0 version is published, you can (and should!) continue to release new versions of it.**
These new versions might include bug fixes (patch releases), additions to the module's public API (minor releases), and even breaking changes. Because a v0 release makes no guarantees of stability or backward compatibility, you can make breaking changes in its versions.
For more, see Publishing bug fixes and Publishing non-breaking API changes.
- **When you're getting a stable version ready for release, you publish pre-releases as alphas and betas.** For more, see Publishing pre-release versions.
- **Release a v1 as the first stable release.**
This is the first release that makes commitments about the module's stability. For more, see Publishing the first stable version.
- **In the v1 version, continue to fix bugs and, where necessary, make additions to the module's public API.**
For more, see Publishing bug fixes and Publishing non-breaking API changes.
- **When it can't be avoided, publish breaking changes in a new major version.**
A major version update – such as from v1.x.x to v2.x.x – can be a very disruptive upgrade for your module's users. It should be a last resort. For more, see Publishing breaking API changes.
