Skip to content

Nit: v3.9.0-rc1 downloads links are "rc-1" not "rc1" breaks automated builder #6522

Description

@DazWilkin

What language does this apply to?

This applies to protobuf-* too but I'll use protoc as my example.

The releases links are generally of the form:

https://github.com/google/protobuf/releases/download/v${VERS}/protoc-${VERS}-${ARCH}.zip

The exception to this rule is with rc1 (both 3.9.0-rc1 and 3.8.0-rc1) where the first occurrence in the URL is consistent (v${VERS}) but the second occurrence is hyphenated rc-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.zip

Would 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.zip

I went back to 3.7.0-rc3 and 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.zip

Describe the problem you are trying to solve.

Automating container builds of protoc and 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.

Metadata

Metadata

Assignees

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions