protobuf: revert to 3.12.2 #58104
protobuf: revert to 3.12.2 #58104
Conversation
AustinShalit
force-pushed
the
protobuf-3.12.2
branch
from
3662d05 to
2382d1c
Compare
|
Perhaps we should switch to using |
|
Maybe? The backstory here is I am on a project whose build process requires all protobuf versions (native, Java, Python) to be the same. Protobuf v3.12.3 was never pushed to Maven or PyPI (presumably because it was tagged incorrectly) leading to the direct issue that I am trying to solve. |
|
Note that CI will fail because it thinks this is a downgrade from a stable version. I guess the argument that I am trying to make with this PR is that 3.12.3 is not a stable version and was accidentally released. |
Upstream seem to disagree on that. In fact, the PHP version of 3.12.3 was published to PECL yesterday. |
Likewise here!
Maybe, although no comment on their issue and still no Java: Although they have admitted a likely error here: This is causing issues for others too: |
AustinShalit
force-pushed
the
protobuf-3.12.2
branch
from
2382d1c to
0789342
Compare
|
I've rebased the PR to also revert the build from tar because building from tar will not help the version mismatch issue or issues as described by the comment here: protocolbuffers/protobuf#7632 (comment) |
|
It looks like they are going to cut a release to 3.12.4 soon "because 3.12.3 was also mistakenly tagged at the wrong commit" |
|
Commit f3bbd3e changes this to use the protobuf-all tarball. I think this is a better fix. I had previously modified our build process to compile a deb package from the Git tag, to match Homebrew, now I don't have a good way of installing the latest protoc commit. |
|
If we really want to do this, we need to use When is the next release planned? |
|
They are clearly just having issues with their releases and homebrew doesn't generally revert a version because upstream broke it. It's not up to us to be quality control for everything we ship. |
|
Looks like they are pushing 3.12.4 today. Do we want to revert the build from tar when we bump the version? |
Yes please |
|
I disagree. Upstream clearly support tar archives more than git tags, and using a tarball means less build dependencies. I don’t see any advantage whatsoever in preferring a git clone.
… On 28 Jul 2020, at 21:51, Seeker ***@***.***> wrote:
Do we want to revert the build from tar when we bump the version?
Yes please
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#58104 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJCWYVY6WUH43YNFSGPHY3R5425TANCNFSM4O5AGGFA>.
|
|
The advantage of a git tag is that you can easily reproduce what's in the Homebrew release by cloning the repo and checking out the given git tag. It is unclear how they are building tarballs, and they have at least once put incorrect contents in it. |
|
It was working great with the git tag method before 3.12.3 and switching to the tarball method did not fix the issue that this PR was trying to fix. Seems like the burden should be on those who want to use the tarball method rather than those who want to use the git clone method. As an aside, this conversation would've been great to have in a pull request to switch to the tarball method rather than after a direct commit to the repo. But that is water under the bridge at this point; just something to learn from. |
No, it was not intended to fix the issue of upstream not uploading artifacts for other languages to PECL etc - only upstream can fix that. It was intended to revert the breaking changes that were introduced from the misplaced git tag, which broke dependents like caffe. It did that job successfully.
We've always preferred distribution tarballs, where available. I'm fine with using git tags if there's a strong reason for protobuf to be different than everything else.
That would indeed be an issue. Do you know when that was? I'm not finding anything on the issue tracker.
It was not a direct commit to the repo. The pull request was open for around 12 hours (with no objections, and none afterwards), and would have been longer if the git tag wasn't causing actual real-world issues like #58210. It's unfortunate that the breaking change issue with the git tag wasn't caught earlier, but it ultimately makes the transition to 3.12.4 easier as 3.12.4 would have otherwise been another breaking change moving the tag to the correct branch - no revision bumps should be required to dependents as a result. |
|
Sorry for the misunderstanding everyone 😰 For reference, this is the PR that switched to using tarball: #58229 |
This reverts commit a4511d0.
This reverts commit 13b1c5f.
brew install --build-from-source <formula>, where<formula>is the name of the formula you're submitting?brew test <formula>, where<formula>is the name of the formula you're submitting?brew audit --strict <formula>(after doingbrew install <formula>)?There are multiple issues with the 3.12.3 release of protobuf that the maintainers said would be fixed with a 3.12.4 release but that update has not arrived. These issues are with the release itself and not particular bugs in the library.
protocolbuffers/protobuf#7600
protocolbuffers/protobuf#7632
protocolbuffers/protobuf#7637
protocolbuffers/protobuf#7627