Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

protoc-gen-go: emit versioning information #524

Closed
dsnet opened this issue Feb 21, 2018 · 14 comments
Closed

protoc-gen-go: emit versioning information #524

dsnet opened this issue Feb 21, 2018 · 14 comments

Comments

@dsnet
Copy link
Member

dsnet commented Feb 21, 2018

The generator currently emits the following:

// Code generated by protoc-gen-go. DO NOT EDIT.
// source: extension_user/extension_user.proto

We should improve this by adding information about the versions:

  1. What go toolchain was used (e.g., go1.9.6)
  2. What version of protoc was used (e.g., libprotoc 3.5.1)
  3. What version of protoc-gen-go was used

The 3rd item is harder to do, but the upcoming version control features in the Go toolchain will help with this. My understanding is that one of the features it will provide is a cryptographic signing of all the Go packages that went into building that binary.

For now, I would be happy to just see items 1 and 2 start being encoded in the generated infolog.
@dsnet dsnet mentioned this issue Feb 21, 2018
Merged
@dsnet
Copy link
Member Author

dsnet commented Feb 21, 2018

Furthermore, any special options passed to protoc-gen-go should probably be provided in that log. For example, whether the grpc plugin is used.

@dsnet
Copy link
Member Author

dsnet commented Feb 21, 2018

Related: #384

@neild
Copy link
Contributor

neild commented Feb 21, 2018

If we do this, we should also make "make regenerate" produce an error when run with the "wrong" (non-canonical) version of the toolchain.

@dsnet
Copy link
Member Author

dsnet commented Feb 21, 2018

If we do this, we should also make "make regenerate" produce an error when run with the "wrong" (non-canonical) version of the toolchain.

That sounds fine to me. However, I don't think that's this issue, but what @tamird is trying address in #521.

@dsnet dsnet mentioned this issue May 10, 2018
Closed
@stevenroose stevenroose mentioned this issue May 10, 2018
Closed
@dsnet
Copy link
Member Author

dsnet commented Jun 9, 2018 •
edited
Loading

If it wasn't clear, this issue should address both generated code and also provide a command-line flag to check this information, but we will wait for vgo support before doing this.

@awalterschulze awalterschulze mentioned this issue Jun 18, 2018
Closed
@dsnet
Copy link
Member Author

dsnet commented Aug 7, 2018

This is blocked on golang/go#26404

@oscarpicas oscarpicas mentioned this issue Nov 28, 2018
Closed
@zeevallin
Copy link

What is the status on the command line flag?

@dsnet
Copy link
Member Author

dsnet commented Dec 18, 2018

Still blocked on golang/go#26404, which is slated for release in Go1.12.

@metasyn
Copy link

metasyn commented Jan 22, 2019

Sounds like it is unblocked now, with go 1.12 released & golang/go#24604 closed?

@rocco-haro
Copy link

Any updates on this?

@thsaravana
Copy link

@dsnet Any update on this?

gopherbot pushed a commit to protocolbuffers/protobuf-go that referenced this issue Aug 7, 2019
@dsnet
runtime/protoimpl, cmd/protoc-gen-go: support release versioning
bab3d40 
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>
@dsnet dsnet added this to the v2 release milestone Aug 21, 2019
@dsnet dsnet mentioned this issue Nov 14, 2019
Closed
@RahulMitra
Copy link

@dsnet any update on this?

@dsnet
Copy link
Member Author

dsnet commented Jan 31, 2020

This is already resolved in the v2 branch. The v2 release is targeting end of Q1.

@dsnet
Copy link
Member Author

dsnet commented Mar 3, 2020 •
edited
Loading

This is fixed in the v1.20.0 release of protoc-gen-go.

$ ./protoc-gen-go --version
protoc-gen-go v1.20.0

@dsnet dsnet closed this as completed Mar 3, 2020
@golang golang locked as resolved and limited conversation to collaborators Jun 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@neild @zeevallin @RahulMitra @metasyn @dsnet @thsaravana @rocco-haro