package version
Import Path
google.golang.org/protobuf/internal/version (on go.dev)
Dependency Relation
imports 2 packages, and imported by one package
Involved Source Files
Package version records versioning information about this module.
Package-Level Functions (only one, which is exported)
String formats the version string for this module in semver format.
Examples:
v1.20.1
v1.21.0-rc.1
Package-Level Constants (total 4, all are exported)
These constants determine the current version of this module.
For our release process, we enforce the following rules:
* Tagged releases use a tag that is identical to String.
* Tagged releases never reference a commit where the String
contains "devel".
* The set of all commits in this repository where String
does not contain "devel" must have a unique String.
Steps for tagging a new release:
1. Create a new CL.
2. Update Minor, Patch, and/or PreRelease as necessary.
PreRelease must not contain the string "devel".
3. Since the last released minor version, have there been any changes to
generator that relies on new functionality in the runtime?
If yes, then increment RequiredGenerated.
4. Since the last released minor version, have there been any changes to
the runtime that removes support for old .pb.go source code?
If yes, then increment SupportMinimum.
5. Send out the CL for review and submit it.
Note that the next CL in step 8 must be submitted after this CL
without any other CLs in-between.
6. Tag a new version, where the tag is is the current String.
7. Write release notes for all notable changes
between this release and the last release.
8. Create a new CL.
9. Update PreRelease to include the string "devel".
For example: "" -> "devel" or "rc.1" -> "rc.1.devel"
10. Send out the CL for review and submit it.
These constants determine the current version of this module.
For our release process, we enforce the following rules:
* Tagged releases use a tag that is identical to String.
* Tagged releases never reference a commit where the String
contains "devel".
* The set of all commits in this repository where String
does not contain "devel" must have a unique String.
Steps for tagging a new release:
1. Create a new CL.
2. Update Minor, Patch, and/or PreRelease as necessary.
PreRelease must not contain the string "devel".
3. Since the last released minor version, have there been any changes to
generator that relies on new functionality in the runtime?
If yes, then increment RequiredGenerated.
4. Since the last released minor version, have there been any changes to
the runtime that removes support for old .pb.go source code?
If yes, then increment SupportMinimum.
5. Send out the CL for review and submit it.
Note that the next CL in step 8 must be submitted after this CL
without any other CLs in-between.
6. Tag a new version, where the tag is is the current String.
7. Write release notes for all notable changes
between this release and the last release.
8. Create a new CL.
9. Update PreRelease to include the string "devel".
For example: "" -> "devel" or "rc.1" -> "rc.1.devel"
10. Send out the CL for review and submit it.
These constants determine the current version of this module.
For our release process, we enforce the following rules:
* Tagged releases use a tag that is identical to String.
* Tagged releases never reference a commit where the String
contains "devel".
* The set of all commits in this repository where String
does not contain "devel" must have a unique String.
Steps for tagging a new release:
1. Create a new CL.
2. Update Minor, Patch, and/or PreRelease as necessary.
PreRelease must not contain the string "devel".
3. Since the last released minor version, have there been any changes to
generator that relies on new functionality in the runtime?
If yes, then increment RequiredGenerated.
4. Since the last released minor version, have there been any changes to
the runtime that removes support for old .pb.go source code?
If yes, then increment SupportMinimum.
5. Send out the CL for review and submit it.
Note that the next CL in step 8 must be submitted after this CL
without any other CLs in-between.
6. Tag a new version, where the tag is is the current String.
7. Write release notes for all notable changes
between this release and the last release.
8. Create a new CL.
9. Update PreRelease to include the string "devel".
For example: "" -> "devel" or "rc.1" -> "rc.1.devel"
10. Send out the CL for review and submit it.
These constants determine the current version of this module.
For our release process, we enforce the following rules:
* Tagged releases use a tag that is identical to String.
* Tagged releases never reference a commit where the String
contains "devel".
* The set of all commits in this repository where String
does not contain "devel" must have a unique String.
Steps for tagging a new release:
1. Create a new CL.
2. Update Minor, Patch, and/or PreRelease as necessary.
PreRelease must not contain the string "devel".
3. Since the last released minor version, have there been any changes to
generator that relies on new functionality in the runtime?
If yes, then increment RequiredGenerated.
4. Since the last released minor version, have there been any changes to
the runtime that removes support for old .pb.go source code?
If yes, then increment SupportMinimum.
5. Send out the CL for review and submit it.
Note that the next CL in step 8 must be submitted after this CL
without any other CLs in-between.
6. Tag a new version, where the tag is is the current String.
7. Write release notes for all notable changes
between this release and the last release.
8. Create a new CL.
9. Update PreRelease to include the string "devel".
For example: "" -> "devel" or "rc.1" -> "rc.1.devel"
10. Send out the CL for review and submit it.
 |
The pages are generated with Golds v0.3.2. (GOOS=linux GOARCH=amd64) Golds is a Go 101 project developed by Tapir Liu. PR and bug reports are welcome and can be submitted to the issue list. Please follow @Go100and1 (reachable from the left QR code) to get the latest news of Golds. |