Skip to content
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

[Workloads] Publish a WorkloadDependencies file inside each manifest pack #21768

Closed
Redth opened this issue Dec 6, 2024 · 3 comments · Fixed by #21779
Closed

[Workloads] Publish a WorkloadDependencies file inside each manifest pack #21768

Redth opened this issue Dec 6, 2024 · 3 comments · Fixed by #21779
Assignees
Milestone

Comments

@Redth
Copy link
Member

Redth commented Dec 6, 2024

For any given version of any of the ios/maccat/tvos/macos workloads, this repository is the source of truth for knowledge such as "which XCode version is compatible".

We are beginning to include this type of information inside of the workload manifest packs so that the metadata can be later inferred by things like tooling (eg: vscode) to validate the correctness of developer environments, as well as to help automate publishing accurate and up to date release information in docs.

The file should be a json file inside of the workload package in the path:

  • /data/WorkloadDependencies.json

Mac/iOS does not have a lot of information to describe, but an example of what this should look like for these workloads is:

{
  "microsoft.net.sdk.ios" : {
    "workload": {
        "alias": [ "ios" ],
        "version": "18.0.8316"
    },
    "xcode": {
      "version": "[16.0,)",
      "recommendedVersion": "16.0"
    },
    "sdk": {
      "version": "18.0"
    }
  }
}

We should publish one of these files for each manifest package with the relevant information (so there would be one for maccat, tvos, macos as well).

The workload identifier is used as a top level key so that these files may be eventually merged into one json file when the workload version set package is built.

Note that some version fields can be described as NuGet version ranges where it makes sense (eg: xcode version) to describe a known compatible set of ranges (this can be used to block scenarios like xcode 17.0 being considered 'supported'). The recommended version should indicate which version to install if we were going to suggest picking one.

We should add any other useful information that could help describe things such as versions of tools used/recommended to developers to setup consistent and reliable CI/CD and development environments with. For example, Android's file will describe the desired JDK version along with versions of emulators to use and the appropriate source id to install via sdk manager for each.

Ref (loop)

@rolfbjarne
Copy link
Member

@Redth is this a .NET 10 task, or do you want it earlier?

@Redth
Copy link
Member Author

Redth commented Dec 6, 2024

@rolfbjarne we are hoping to start this as soon as possible so we can begin to look at using it in tooling scenarios, so net 9 :)

@rolfbjarne
Copy link
Member

PR is up: #21779, please review!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants