protoc-gen-go: Add -version flag to print version #599
Conversation
|
Unfortunately, v1.1.0 has already been tagged, so we can't retroactively add this functionality without tagging another minor version (for which this is not worth a minor release on its own). |
|
Also, I'd rather not hard-code a version string as it is easy for that to get out of sync with the repository tag. Instead, I rather wait for proper versioning support to come with golang/go#24301. It's not just the version of |
Of course. I just added the latest version, so that it could be updated whenever a new release was made.
I agree that an automatic way to include the version into the code would be safer. However I didn't know of any. Waiting for vgo might make sense, but could take more time. |
It's certainly the correct path forward to fixing this. Russ is aiming to get vgo support into Go1.11, which is 3 months out. I'd rather wait for that. Is there something that absolutely requires versioning info now? Or is this just a "nice to have"? |
|
It's just cumbersome that in open-source project it's virtually impossible
to make changes to proto files and commit the respective changes to the
generated code, since a single update in any of the several used packages
(protoc, protoc-gen-go, protoc-gen-grpc-gateway, protoc-gen-swagger) will
change things that shouldn't be changed. So basically a PR to a proto file
has to be followed by a commit from the maintainer that has a consistent
setup.
…On Fri, May 11, 2018 at 8:40 PM, Joe Tsai ***@***.***> wrote:
Waiting for vgo might make sense, but could take more time.
It's certainly the correct path forward to fixing this. Russ is aiming to
get vgo support into Go1.11, which is 3 months out. I'd rather wait for
that.
Is there something that absolutely requires versioning info now? Or is
this just a "nice to have"?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#599 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA0F3CgCxVv4tLLwRMjtivBh2bsnEnfdks5txdsFgaJpZM4T6K0g>
.
|
|
Closing this in favor of vgo support, which is moving along. |
|
vgo doesn't really solve this. This is about external tools being able to determine the version of the executable. |
|
Maybe this should wait until the upcoming |
|
I'm ok with waiting until a good approach is figured out. But if it's closed, I feel like it'll be forgotten about soon :) |
|
Agreed. I've been struggling with the same problem in some projects of mine, and have temporarily added hard-coded version constants in a couple. I started watching this thread in the hopes that a better idea would come up :) |
|
I do care about having good versioning strings in protoc-gen-go, but I'm not fond of doing extra plumbing work for something that will probably be solved in the coming months. There are many other protobuf issues to address that is probably better to spend the limited time on. |
|
I totally agree. But again, there's no harm in this issue being open and low priority. |
|
Perhaps, I'm misunderstanding something, but there is an open issue for this? #524 |
|
That issue is about logging the version used in the generated code.
That's different than having the executable log its version (like almost all GNU executables do, fwiw) so that tooling can check this version before generating new code. |
|
That issue is a superset of the functionality requested here. I still want item 3 in that list (which is why that issue is still open). Once #524 is achievable, it is trivial to expose a command-line flag that exposes this information. I think we're spending time debating the same thing. |
Fixes #598 and partially #524.