Nit: v3.9.0-rc1 downloads links are "rc-1" not "rc1" breaks automated builder #6522
Assignees
Labels
Comments
|
@anandolee can we change our dist script to create the zip file? |
|
We use the version in protoc-artifacts/pom.xml. |
|
OK. Thanks. |
cpovirk
added a commit
to google/truth
that referenced
this issue
Jul 24, 2023
Notes: - The GWT bump requires changing the browser setting from "FF38" to "FF." - I skipped the `jsinterop-annotations` bump to 2.1.0 because it's built with `-target 11`, while we still support 8. (Closes #1147) (I've noted this in google/guava#6614) - The command I used is: ``` mvn org.codehaus.mojo:versions-maven-plugin:2.16.0:{update-properties,use-latest-releases} -DgenerateBackupPoms=false -Dexcludes=com.google.guava:guava ``` That tried to update protobuf to a release candidate. I had thought that perhaps this was the result of [a protobuf change from "-rc1" to "-rc-1"](protocolbuffers/protobuf#6522), but I'm wondering if it's actually just that `versions-maven-plugin` (in contrast to Dependabot) counts release candidates [as releases](https://www.mojohaus.org/versions/versions-maven-plugin/use-latest-releases-mojo.html)? I'd have to investigate further and perhaps [use `rulesUri`](https://stackoverflow.com/a/46935363/28465). But since we normally rely on Dependabot (and I was using `versions-maven-plugin` here only "to make things easier"... :)), I'm not going to worry about it now.
cpovirk
added a commit
to google/truth
that referenced
this issue
Jul 24, 2023
Notes: - The GWT bump requires changing the browser setting from "FF38" to "FF." - I skipped the `jsinterop-annotations` bump to 2.1.0 because it's built with `-target 11`, while we still support 8. (Closes #1147) (I've noted this in google/guava#6614) - The command I used is: ``` mvn org.codehaus.mojo:versions-maven-plugin:2.16.0:{update-properties,use-latest-releases} -DgenerateBackupPoms=false -Dexcludes=com.google.guava:guava ``` That tried to update protobuf to a release candidate. I had thought that perhaps this was the result of [a protobuf change from "-rc1" to "-rc-1"](protocolbuffers/protobuf#6522), but I'm wondering if it's actually just that `versions-maven-plugin` (in contrast to Dependabot) counts release candidates [as releases](https://www.mojohaus.org/versions/versions-maven-plugin/use-latest-releases-mojo.html)? I'd have to investigate further and perhaps [use `rulesUri`](https://stackoverflow.com/a/46935363/28465). But since we normally rely on Dependabot (and I was using `versions-maven-plugin` here only "to make things easier"... :)), I'm not going to worry about it now. ... Also, it looks like protobuf 4 might remove the `hasPresence()` method that we'd migrated to back in cl/508716698. If so, there's a good chance that the protobuf team will fix things for us :) If not, I'm assuming that this will relate to ["Editions."](https://protobuf.dev/editions/overview/)
cpovirk
added a commit
to google/truth
that referenced
this issue
Jul 24, 2023
Notes: - The GWT bump requires changing the browser setting from "FF38" to "FF." - I skipped the `jsinterop-annotations` bump to 2.1.0 because it's built with `-target 11`, while we still support 8. (Closes #1147) (I've noted this in google/guava#6614) - The command I used is: ``` mvn org.codehaus.mojo:versions-maven-plugin:2.16.0:{update-properties,use-latest-releases} -DgenerateBackupPoms=false -Dexcludes=com.google.guava:guava ``` That tried to update protobuf to a release candidate. I had thought that perhaps this was the result of [a protobuf change from "-rc1" to "-rc-1"](protocolbuffers/protobuf#6522), but I'm wondering if it's actually just that `versions-maven-plugin` (in contrast to Dependabot) counts release candidates [as releases](https://www.mojohaus.org/versions/versions-maven-plugin/use-latest-releases-mojo.html)? I'd have to investigate further and perhaps [use `rulesUri`](https://stackoverflow.com/a/46935363/28465). But since we normally rely on Dependabot (and I was using `versions-maven-plugin` here only "to make things easier"... :)), I'm not going to worry about it now. ... Also, it looks like protobuf 4 might remove the `hasPresence()` method that we'd migrated to back in cl/508716698. If so, there's a good chance that the protobuf team will fix things for us :) If not, I'm assuming that this will relate to ["Editions."](https://protobuf.dev/editions/overview/) Fixes #1149 Fixes #1148 Fixes #1146 Fixes #1145
copybara-service bot
pushed a commit
to google/truth
that referenced
this issue
Jul 24, 2023
Notes: - The GWT bump requires changing the browser setting from "FF38" to "FF." - I skipped the `jsinterop-annotations` bump to 2.1.0 because it's built with `-target 11`, while we still support 8. (Closes #1147) (I've noted this in google/guava#6614) - The command I used is: ``` mvn org.codehaus.mojo:versions-maven-plugin:2.16.0:{update-properties,use-latest-releases} -DgenerateBackupPoms=false -Dexcludes=com.google.guava:guava ``` That tried to update protobuf to a release candidate. I had thought that perhaps this was the result of [a protobuf change from "-rc1" to "-rc-1"](protocolbuffers/protobuf#6522), but I'm wondering if it's actually just that `versions-maven-plugin` (in contrast to Dependabot) counts release candidates [as releases](https://www.mojohaus.org/versions/versions-maven-plugin/use-latest-releases-mojo.html)? I'd have to investigate further and perhaps [use `rulesUri`](https://stackoverflow.com/a/46935363/28465). But since we normally rely on Dependabot (and I was using `versions-maven-plugin` here only "to make things easier"... :)), I'm not going to worry about it now. ... Also, it looks like protobuf 4 might remove the `hasPresence()` method that we'd migrated to back in cl/508716698. If so, there's a good chance that the protobuf team will fix things for us :) If not, I'm assuming that this will relate to ["Editions."](https://protobuf.dev/editions/overview/) Fixes #1149 Fixes #1148 Fixes #1146 Fixes #1145 Fixes #1150 RELNOTES=n/a PiperOrigin-RevId: 550553262
copybara-service bot
pushed a commit
to google/truth
that referenced
this issue
Jul 24, 2023
Notes: - The GWT bump requires changing the browser setting from "FF38" to "FF." - I skipped the `jsinterop-annotations` bump to 2.1.0 because it's built with `-target 11`, while we still support 8. (Closes #1147) (I've noted this in google/guava#6614) - The command I used is: ``` mvn org.codehaus.mojo:versions-maven-plugin:2.16.0:{update-properties,use-latest-releases} -DgenerateBackupPoms=false -Dexcludes=com.google.guava:guava ``` That tried to update protobuf to a release candidate. I had thought that perhaps this was the result of [a protobuf change from "-rc1" to "-rc-1"](protocolbuffers/protobuf#6522), but I'm wondering if it's actually just that `versions-maven-plugin` (in contrast to Dependabot) counts release candidates [as releases](https://www.mojohaus.org/versions/versions-maven-plugin/use-latest-releases-mojo.html)? I'd have to investigate further and perhaps [use `rulesUri`](https://stackoverflow.com/a/46935363/28465). But since we normally rely on Dependabot (and I was using `versions-maven-plugin` here only "to make things easier"... :)), I'm not going to worry about it now. ... Also, it looks like protobuf 4 might remove the `hasPresence()` method that we'd migrated to back in cl/508716698. If so, there's a good chance that the protobuf team will fix things for us :) If not, I'm assuming that this will relate to ["Editions."](https://protobuf.dev/editions/overview/) Fixes #1149 Fixes #1148 Fixes #1146 Fixes #1145 Fixes #1150 RELNOTES=n/a PiperOrigin-RevId: 550560426
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What language does this apply to?
This applies to
protobuf-*too but I'll useprotocas my example.The releases links are generally of the form:
https://github.com/google/protobuf/releases/download/v${VERS}/protoc-${VERS}-${ARCH}.zipThe exception to this rule is with
rc1(both3.9.0-rc1and3.8.0-rc1) where the first occurrence in the URL is consistent (v${VERS}) but the second occurrence is hyphenatedrc-1..../v3.9.0-rc1/protoc-3.9.0-rc-1-linux-x86_64.zip.../v3.8.0-rc1/protoc-3.8.0-rc-1-linux-x86_64.zipWould prefer:
.../v3.9.0-rc1/protoc-3.9.0-rc1-linux-x86_64.zip.../v3.8.0-rc1/protoc-3.8.0-rc1-linux-x86_64.zipI went back to
3.7.0-rc3and this has a period added on first occurrence and a hyphen on second occurrence:.../v3.7.0-rc.3/protoc-3.7.0-rc-3-linux-x86_64.zipDescribe the problem you are trying to solve.
Automating container builds of
protocand permitting build args for the version and arch.See the example for Google's Cloud Build community builder for
protoc:https://github.com/GoogleCloudPlatform/cloud-builders-community/blob/master/protoc/Dockerfile
Describe the solution you'd like
Reasonable (!) consistency in the release download URL generation of future releases such that, for the near-term, release URLs can be determined from the version and arch.
Describe alternatives you've considered
Permitting the builds to fail when release candidate versions are produced.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: