Skip to content

[5.8][Registry] Make 'Content-Version' optional for archive and manifest download API #6156

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 15, 2023

Conversation

yim-lee
Copy link
Contributor

@yim-lee yim-lee commented Feb 14, 2023

Cherry picking #6153 to 5.8.
The API spec changes are the same, but the implementation is different.

Motivation:
The 'Content-Version' header is required in all registry server responses to indicate API version. However, it shouldn't be required for responses that don't/can't change, such as the download archive and fetch package manifest endpoints. This may also cause problems for registry that have these files hosted elsewhere, because they may not have full control over response headers.

Modifications:

  • Modify registry API spec to make 'Content-Version' optional for the said endpoints
  • Adjust RegistryClient

rdar://105415468

…ownload API

Motivation:
The 'Content-Version' header is required in all registry server responses to indicate API version.
However, it shouldn't be required for responses that don't/can't change, such as the download
archive and fetch package manifest endpoints. This may also cause problems for registry that have
these files hosted elsewhere, because they may not have full control over response headers.

Modifications:
- Modify registry API spec to make 'Content-Version' optional for the said endpoints
- Adjust `RegistryClient`

rdar://105415468
@yim-lee
Copy link
Contributor Author

yim-lee commented Feb 14, 2023

@swift-ci please smoke test

1 similar comment
@yim-lee
Copy link
Contributor Author

yim-lee commented Feb 14, 2023

@swift-ci please smoke test

@yim-lee
Copy link
Contributor Author

yim-lee commented Feb 14, 2023

@swift-ci please smoke test Windows

@tomerd tomerd added the swift 5.8 This PR targets the 5.8 branch label Feb 14, 2023
@yim-lee
Copy link
Contributor Author

yim-lee commented Feb 14, 2023

Seeing this in the Windows build:

C:\Users\swift-ci\jenkins\workspace\swiftpm-PR-windows\swift-tools-support-core\Sources\TSCBasic\FileSystem.swift:14:8: error: module compiled with Swift 5.9 cannot be imported by the Swift 5.8 compiler: T:\6\swift\SystemPackage.swiftmodule

import SystemPackage

@shahmishal How do we get 5.8 CI going for Windows?

@tomerd
Copy link
Contributor

tomerd commented Feb 15, 2023

windows failure does not seem to be related, okay to merge to not block progress

@shahmishal
Copy link
Member

@compnerd Do you know what's going on with this failure?

@compnerd
Copy link
Member

@shahmishal - looks like an infrastructure issue? It seems that it didn't do a clean build?

C:\Users\swift-ci\jenkins\workspace\swiftpm-PR-windows\swift-tools-support-core\Sources\TSCBasic\FileSystem.swift:14:8: error: module compiled with Swift 5.9 cannot be imported by the Swift 5.8 compiler: T:\6\swift\SystemPackage.swiftmodule

@tomerd
Copy link
Contributor

tomerd commented Feb 15, 2023

@yim-lee since this is a spot change that is not platform specific, I think we dont need to hold on the Windows issue which is unrelated

@yim-lee yim-lee merged commit 597b99f into swiftlang:release/5.8 Feb 15, 2023
@yim-lee yim-lee deleted the optional-api-version-5.8 branch February 15, 2023 19:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
swift 5.8 This PR targets the 5.8 branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants