Add version number to generated python files
This adds the version of the protoc compiler that generated the python files to the header of the generated files as specified in #11085
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
View this failed invocation of the CLA check for more information.
For the most up to date status, view the checks section at the bottom of the pull request.
If this feature is also wanted for the other languages should I include that within this PR, or should different PRs be opened for each language?
If this feature is also wanted for the other languages should I include that within this PR, or should different PRs be opened for each language?
It would be great if you could add them to this PR!
I've noticed there are unit tests in the ruby compiler directory. From what I understand they compare output to the expected files in that dir. This will break that test, and will make it hard to maintain it in the future as the output will change with every new version.
- Are there similar tests for the other languages as well? If so how should I move forward with this so that they don't fail, while not making them a maintenance issue?
- Should I contribute this change to the Go, JavaScript, and Dart compilers too, given that they're in other repos?
I've noticed there are unit tests in the ruby compiler directory. From what I understand they compare output to the expected files in that dir. This will break that test, and will make it hard to maintain it in the future as the output will change with every new version.
- Are there similar tests for the other languages as well? If so how should I move forward with this so that they don't fail, while not making them a maintenance issue?
Talked with the team about this and we are going to create an easier way to update the expected output for changes like this to decrease the maintenance burden. Can you make the manual change for the Ruby expected files for this time though?
- Should I contribute this change to the Go, JavaScript, and Dart compilers too, given that they're in other repos?
Up to you, we don't work on those repos and it's not organized the same so it may be a bit of extra work for you but I think those repo managers would appreciate it.
Talked with the team about this and we are going to create an easier way to update the expected output for changes like this to decrease the maintenance burden. Can you make the manual change for the Ruby expected files for this time though?
Done
I think you also need to run generate_descriptor_proto.sh to update C++ tests that compare the generated output.
Sorry I'm just getting back to this, can you update your branch and fix conflicts so I can rerun the tests?
Done, please let me know if there's anything else I need to do
Could you rebase this PR against the main branch? Sorry for the trouble, you caught us in the middle of a migration to GitHub Actions.
Sure thing, doing it now
Apologies, I accidentally pushed an incorrect rebase, which could be the reason for the protobuf-btr and protobuf-docs teams' review requests. I rebased and force pushed so that shouldn't be an issue anymore
@deannagarcia it seems that the PR isn't passing the safety check despite having the "safe for tests" label. Is this intentional, if so is there something else I should do on my part? Thanks
@deannagarcia any updates regarding this PR?
Sorry for the delay. This has been really difficult to sync internally because of a difference in versioning. I'm still working on fixing those issues, I will provide an update when I have one.
We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active, please add a comment.
This PR is labeled inactive because the last activity was over 90 days ago. This PR will be closed and archived after 14 additional days without activity.
We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active or becomes active again, please reopen it.
This PR was closed and archived because there has been no new activity in the 14 days since the inactive label was added.