protobuf-go/runtime/protoimpl/version.go

61 lines
2.0 KiB
Go
Raw Normal View History

runtime/protoimpl, cmd/protoc-gen-go: support release versioning In order for protoc-gen-go to output the current version, it needs to know what version it is currently running as. However, we cannot rely on the git tags since the tags are not made until *after* the commit has been submitted. Instead, we manually encode the version into the code and make sure that git tags match up with the version in the code. The version.go file in runtime/protoimpl contains instructions for how to make a release. Essentially: * Every non-release commit has a version string with "devel" in it. * Every release commit must not have "devel" in it and must be unique. * The "release process" involves submitting two CLs. The first CL creates a version string without "devel", which is the commit that a git tag will actually reference. The second CL follows immediately and re-introduces "devel" into the version string. The following example shows a possible sequence of VersionStrings for git commits in time-ascending order: v1.19.0-devel (this CL) v1.19.0-devel v1.19.0-devel v1.19.0-devel v1.20.0-rc.1 <- tagged v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.2 <- tagged v1.20.0-rc.2.devel v1.20.0 <- tagged (future public release) v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.1 <- tagged v1.20.1-devel v1.20.1-devel v1.21.0 <- tagged v1.21.0-devel Note that we start today with v1.19.0-devel, which means that our initial release will be v1.20.0. This number was intentionally chosen since 1) the number 20 has some correlation to the fact that we keep calling the new implementation the "v2" implementation, and 2) the set of tagged versions for github.com/golang/protobuf and google.golang.org/protobuf are unlikely to ever overlap. This way, the version of protoc-gen-go is never ambiguous which module it was built from. Now that we have version information, we add support for generating .pb.go files with the version information recorded. However, we do not emit these for .pb.go files in our own repository since they are always guaranteed to be at the right version (enforced by integration_test.go). Updates golang/protobuf#524 Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117 Reviewed-by: Damien Neil <dneil@google.com>
2019-07-10 07:15:35 +00:00
// Copyright 2019 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package protoimpl
import (
"google.golang.org/protobuf/internal/version"
runtime/protoimpl, cmd/protoc-gen-go: support release versioning In order for protoc-gen-go to output the current version, it needs to know what version it is currently running as. However, we cannot rely on the git tags since the tags are not made until *after* the commit has been submitted. Instead, we manually encode the version into the code and make sure that git tags match up with the version in the code. The version.go file in runtime/protoimpl contains instructions for how to make a release. Essentially: * Every non-release commit has a version string with "devel" in it. * Every release commit must not have "devel" in it and must be unique. * The "release process" involves submitting two CLs. The first CL creates a version string without "devel", which is the commit that a git tag will actually reference. The second CL follows immediately and re-introduces "devel" into the version string. The following example shows a possible sequence of VersionStrings for git commits in time-ascending order: v1.19.0-devel (this CL) v1.19.0-devel v1.19.0-devel v1.19.0-devel v1.20.0-rc.1 <- tagged v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.2 <- tagged v1.20.0-rc.2.devel v1.20.0 <- tagged (future public release) v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.1 <- tagged v1.20.1-devel v1.20.1-devel v1.21.0 <- tagged v1.21.0-devel Note that we start today with v1.19.0-devel, which means that our initial release will be v1.20.0. This number was intentionally chosen since 1) the number 20 has some correlation to the fact that we keep calling the new implementation the "v2" implementation, and 2) the set of tagged versions for github.com/golang/protobuf and google.golang.org/protobuf are unlikely to ever overlap. This way, the version of protoc-gen-go is never ambiguous which module it was built from. Now that we have version information, we add support for generating .pb.go files with the version information recorded. However, we do not emit these for .pb.go files in our own repository since they are always guaranteed to be at the right version (enforced by integration_test.go). Updates golang/protobuf#524 Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117 Reviewed-by: Damien Neil <dneil@google.com>
2019-07-10 07:15:35 +00:00
)
const (
// MaxVersion is the maximum supported version for generated .pb.go files.
// It is always the current version of the module.
MaxVersion = version.Minor
runtime/protoimpl, cmd/protoc-gen-go: support release versioning In order for protoc-gen-go to output the current version, it needs to know what version it is currently running as. However, we cannot rely on the git tags since the tags are not made until *after* the commit has been submitted. Instead, we manually encode the version into the code and make sure that git tags match up with the version in the code. The version.go file in runtime/protoimpl contains instructions for how to make a release. Essentially: * Every non-release commit has a version string with "devel" in it. * Every release commit must not have "devel" in it and must be unique. * The "release process" involves submitting two CLs. The first CL creates a version string without "devel", which is the commit that a git tag will actually reference. The second CL follows immediately and re-introduces "devel" into the version string. The following example shows a possible sequence of VersionStrings for git commits in time-ascending order: v1.19.0-devel (this CL) v1.19.0-devel v1.19.0-devel v1.19.0-devel v1.20.0-rc.1 <- tagged v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.2 <- tagged v1.20.0-rc.2.devel v1.20.0 <- tagged (future public release) v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.1 <- tagged v1.20.1-devel v1.20.1-devel v1.21.0 <- tagged v1.21.0-devel Note that we start today with v1.19.0-devel, which means that our initial release will be v1.20.0. This number was intentionally chosen since 1) the number 20 has some correlation to the fact that we keep calling the new implementation the "v2" implementation, and 2) the set of tagged versions for github.com/golang/protobuf and google.golang.org/protobuf are unlikely to ever overlap. This way, the version of protoc-gen-go is never ambiguous which module it was built from. Now that we have version information, we add support for generating .pb.go files with the version information recorded. However, we do not emit these for .pb.go files in our own repository since they are always guaranteed to be at the right version (enforced by integration_test.go). Updates golang/protobuf#524 Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117 Reviewed-by: Damien Neil <dneil@google.com>
2019-07-10 07:15:35 +00:00
// GenVersion is the runtime version required by generated .pb.go files.
// This is incremented when generated code relies on new functionality
// in the runtime.
GenVersion = 20
runtime/protoimpl, cmd/protoc-gen-go: support release versioning In order for protoc-gen-go to output the current version, it needs to know what version it is currently running as. However, we cannot rely on the git tags since the tags are not made until *after* the commit has been submitted. Instead, we manually encode the version into the code and make sure that git tags match up with the version in the code. The version.go file in runtime/protoimpl contains instructions for how to make a release. Essentially: * Every non-release commit has a version string with "devel" in it. * Every release commit must not have "devel" in it and must be unique. * The "release process" involves submitting two CLs. The first CL creates a version string without "devel", which is the commit that a git tag will actually reference. The second CL follows immediately and re-introduces "devel" into the version string. The following example shows a possible sequence of VersionStrings for git commits in time-ascending order: v1.19.0-devel (this CL) v1.19.0-devel v1.19.0-devel v1.19.0-devel v1.20.0-rc.1 <- tagged v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.2 <- tagged v1.20.0-rc.2.devel v1.20.0 <- tagged (future public release) v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.1 <- tagged v1.20.1-devel v1.20.1-devel v1.21.0 <- tagged v1.21.0-devel Note that we start today with v1.19.0-devel, which means that our initial release will be v1.20.0. This number was intentionally chosen since 1) the number 20 has some correlation to the fact that we keep calling the new implementation the "v2" implementation, and 2) the set of tagged versions for github.com/golang/protobuf and google.golang.org/protobuf are unlikely to ever overlap. This way, the version of protoc-gen-go is never ambiguous which module it was built from. Now that we have version information, we add support for generating .pb.go files with the version information recorded. However, we do not emit these for .pb.go files in our own repository since they are always guaranteed to be at the right version (enforced by integration_test.go). Updates golang/protobuf#524 Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117 Reviewed-by: Damien Neil <dneil@google.com>
2019-07-10 07:15:35 +00:00
// MinVersion is the minimum supported version for generated .pb.go files.
// This is incremented when the runtime drops support for old code.
MinVersion = 0
)
// EnforceVersion is used by code generated by protoc-gen-go
// to statically enforce minimum and maximum versions of this package.
// A compilation failure implies either that:
// - the runtime package is too old and needs to be updated OR
// - the generated code is too old and needs to be regenerated.
runtime/protoimpl, cmd/protoc-gen-go: support release versioning In order for protoc-gen-go to output the current version, it needs to know what version it is currently running as. However, we cannot rely on the git tags since the tags are not made until *after* the commit has been submitted. Instead, we manually encode the version into the code and make sure that git tags match up with the version in the code. The version.go file in runtime/protoimpl contains instructions for how to make a release. Essentially: * Every non-release commit has a version string with "devel" in it. * Every release commit must not have "devel" in it and must be unique. * The "release process" involves submitting two CLs. The first CL creates a version string without "devel", which is the commit that a git tag will actually reference. The second CL follows immediately and re-introduces "devel" into the version string. The following example shows a possible sequence of VersionStrings for git commits in time-ascending order: v1.19.0-devel (this CL) v1.19.0-devel v1.19.0-devel v1.19.0-devel v1.20.0-rc.1 <- tagged v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.2 <- tagged v1.20.0-rc.2.devel v1.20.0 <- tagged (future public release) v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.1 <- tagged v1.20.1-devel v1.20.1-devel v1.21.0 <- tagged v1.21.0-devel Note that we start today with v1.19.0-devel, which means that our initial release will be v1.20.0. This number was intentionally chosen since 1) the number 20 has some correlation to the fact that we keep calling the new implementation the "v2" implementation, and 2) the set of tagged versions for github.com/golang/protobuf and google.golang.org/protobuf are unlikely to ever overlap. This way, the version of protoc-gen-go is never ambiguous which module it was built from. Now that we have version information, we add support for generating .pb.go files with the version information recorded. However, we do not emit these for .pb.go files in our own repository since they are always guaranteed to be at the right version (enforced by integration_test.go). Updates golang/protobuf#524 Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117 Reviewed-by: Damien Neil <dneil@google.com>
2019-07-10 07:15:35 +00:00
//
// The runtime package can be upgraded by running:
//
runtime/protoimpl, cmd/protoc-gen-go: support release versioning In order for protoc-gen-go to output the current version, it needs to know what version it is currently running as. However, we cannot rely on the git tags since the tags are not made until *after* the commit has been submitted. Instead, we manually encode the version into the code and make sure that git tags match up with the version in the code. The version.go file in runtime/protoimpl contains instructions for how to make a release. Essentially: * Every non-release commit has a version string with "devel" in it. * Every release commit must not have "devel" in it and must be unique. * The "release process" involves submitting two CLs. The first CL creates a version string without "devel", which is the commit that a git tag will actually reference. The second CL follows immediately and re-introduces "devel" into the version string. The following example shows a possible sequence of VersionStrings for git commits in time-ascending order: v1.19.0-devel (this CL) v1.19.0-devel v1.19.0-devel v1.19.0-devel v1.20.0-rc.1 <- tagged v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.2 <- tagged v1.20.0-rc.2.devel v1.20.0 <- tagged (future public release) v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.1 <- tagged v1.20.1-devel v1.20.1-devel v1.21.0 <- tagged v1.21.0-devel Note that we start today with v1.19.0-devel, which means that our initial release will be v1.20.0. This number was intentionally chosen since 1) the number 20 has some correlation to the fact that we keep calling the new implementation the "v2" implementation, and 2) the set of tagged versions for github.com/golang/protobuf and google.golang.org/protobuf are unlikely to ever overlap. This way, the version of protoc-gen-go is never ambiguous which module it was built from. Now that we have version information, we add support for generating .pb.go files with the version information recorded. However, we do not emit these for .pb.go files in our own repository since they are always guaranteed to be at the right version (enforced by integration_test.go). Updates golang/protobuf#524 Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117 Reviewed-by: Damien Neil <dneil@google.com>
2019-07-10 07:15:35 +00:00
// go get google.golang.org/protobuf
//
// The generated code can be regenerated by running:
//
runtime/protoimpl, cmd/protoc-gen-go: support release versioning In order for protoc-gen-go to output the current version, it needs to know what version it is currently running as. However, we cannot rely on the git tags since the tags are not made until *after* the commit has been submitted. Instead, we manually encode the version into the code and make sure that git tags match up with the version in the code. The version.go file in runtime/protoimpl contains instructions for how to make a release. Essentially: * Every non-release commit has a version string with "devel" in it. * Every release commit must not have "devel" in it and must be unique. * The "release process" involves submitting two CLs. The first CL creates a version string without "devel", which is the commit that a git tag will actually reference. The second CL follows immediately and re-introduces "devel" into the version string. The following example shows a possible sequence of VersionStrings for git commits in time-ascending order: v1.19.0-devel (this CL) v1.19.0-devel v1.19.0-devel v1.19.0-devel v1.20.0-rc.1 <- tagged v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.2 <- tagged v1.20.0-rc.2.devel v1.20.0 <- tagged (future public release) v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.1 <- tagged v1.20.1-devel v1.20.1-devel v1.21.0 <- tagged v1.21.0-devel Note that we start today with v1.19.0-devel, which means that our initial release will be v1.20.0. This number was intentionally chosen since 1) the number 20 has some correlation to the fact that we keep calling the new implementation the "v2" implementation, and 2) the set of tagged versions for github.com/golang/protobuf and google.golang.org/protobuf are unlikely to ever overlap. This way, the version of protoc-gen-go is never ambiguous which module it was built from. Now that we have version information, we add support for generating .pb.go files with the version information recorded. However, we do not emit these for .pb.go files in our own repository since they are always guaranteed to be at the right version (enforced by integration_test.go). Updates golang/protobuf#524 Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117 Reviewed-by: Damien Neil <dneil@google.com>
2019-07-10 07:15:35 +00:00
// protoc --go_out=${PROTOC_GEN_GO_ARGS} ${PROTO_FILES}
//
// Example usage by generated code:
//
runtime/protoimpl, cmd/protoc-gen-go: support release versioning In order for protoc-gen-go to output the current version, it needs to know what version it is currently running as. However, we cannot rely on the git tags since the tags are not made until *after* the commit has been submitted. Instead, we manually encode the version into the code and make sure that git tags match up with the version in the code. The version.go file in runtime/protoimpl contains instructions for how to make a release. Essentially: * Every non-release commit has a version string with "devel" in it. * Every release commit must not have "devel" in it and must be unique. * The "release process" involves submitting two CLs. The first CL creates a version string without "devel", which is the commit that a git tag will actually reference. The second CL follows immediately and re-introduces "devel" into the version string. The following example shows a possible sequence of VersionStrings for git commits in time-ascending order: v1.19.0-devel (this CL) v1.19.0-devel v1.19.0-devel v1.19.0-devel v1.20.0-rc.1 <- tagged v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.2 <- tagged v1.20.0-rc.2.devel v1.20.0 <- tagged (future public release) v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.1 <- tagged v1.20.1-devel v1.20.1-devel v1.21.0 <- tagged v1.21.0-devel Note that we start today with v1.19.0-devel, which means that our initial release will be v1.20.0. This number was intentionally chosen since 1) the number 20 has some correlation to the fact that we keep calling the new implementation the "v2" implementation, and 2) the set of tagged versions for github.com/golang/protobuf and google.golang.org/protobuf are unlikely to ever overlap. This way, the version of protoc-gen-go is never ambiguous which module it was built from. Now that we have version information, we add support for generating .pb.go files with the version information recorded. However, we do not emit these for .pb.go files in our own repository since they are always guaranteed to be at the right version (enforced by integration_test.go). Updates golang/protobuf#524 Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117 Reviewed-by: Damien Neil <dneil@google.com>
2019-07-10 07:15:35 +00:00
// const (
// // Verify that this generated code is sufficiently up-to-date.
// _ = protoimpl.EnforceVersion(genVersion - protoimpl.MinVersion)
// // Verify that runtime/protoimpl is sufficiently up-to-date.
// _ = protoimpl.EnforceVersion(protoimpl.MaxVersion - genVersion)
// )
//
// The genVersion is the current minor version used to generated the code.
// This compile-time check relies on negative integer overflow of a uint
// being a compilation failure (guaranteed by the Go specification).
type EnforceVersion uint
// This enforces the following invariant:
//
runtime/protoimpl, cmd/protoc-gen-go: support release versioning In order for protoc-gen-go to output the current version, it needs to know what version it is currently running as. However, we cannot rely on the git tags since the tags are not made until *after* the commit has been submitted. Instead, we manually encode the version into the code and make sure that git tags match up with the version in the code. The version.go file in runtime/protoimpl contains instructions for how to make a release. Essentially: * Every non-release commit has a version string with "devel" in it. * Every release commit must not have "devel" in it and must be unique. * The "release process" involves submitting two CLs. The first CL creates a version string without "devel", which is the commit that a git tag will actually reference. The second CL follows immediately and re-introduces "devel" into the version string. The following example shows a possible sequence of VersionStrings for git commits in time-ascending order: v1.19.0-devel (this CL) v1.19.0-devel v1.19.0-devel v1.19.0-devel v1.20.0-rc.1 <- tagged v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.2 <- tagged v1.20.0-rc.2.devel v1.20.0 <- tagged (future public release) v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.1 <- tagged v1.20.1-devel v1.20.1-devel v1.21.0 <- tagged v1.21.0-devel Note that we start today with v1.19.0-devel, which means that our initial release will be v1.20.0. This number was intentionally chosen since 1) the number 20 has some correlation to the fact that we keep calling the new implementation the "v2" implementation, and 2) the set of tagged versions for github.com/golang/protobuf and google.golang.org/protobuf are unlikely to ever overlap. This way, the version of protoc-gen-go is never ambiguous which module it was built from. Now that we have version information, we add support for generating .pb.go files with the version information recorded. However, we do not emit these for .pb.go files in our own repository since they are always guaranteed to be at the right version (enforced by integration_test.go). Updates golang/protobuf#524 Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117 Reviewed-by: Damien Neil <dneil@google.com>
2019-07-10 07:15:35 +00:00
// MinVersion ≤ GenVersion ≤ MaxVersion
const (
_ = EnforceVersion(GenVersion - MinVersion)
_ = EnforceVersion(MaxVersion - GenVersion)
)