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

[mono] Only ship runtime packs that are classified as mobile targets #104307

Merged
merged 2 commits into from
Aug 5, 2024

Conversation

steveisok
Copy link
Member

In past .NET releases, we have shipped mono runtime packs for most of our support matrix. Starting in .NET 9, we will pull this back significantly and only ship runtime packs that are targeted at our 'mobile' platforms. This includes apple, android, wasm, and wasi targets.

In past .NET releases, we have shipped mono runtime packs for most of our support matrix. Starting in .NET 9, we will pull this back significantly and only ship runtime packs that are targeted at our 'mobile' platforms. This includes apple, android, wasm, and wasi targets.
@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Jul 2, 2024
@steveisok steveisok requested a review from a team July 2, 2024 17:08
@ViktorHofer
Copy link
Member

Just for my own understanding, why do we still produce and upload them to the transport feed?

@steveisok
Copy link
Member Author

Just for my own understanding, why do we still produce and upload them to the transport feed?

If that's the best non-shipping feed, yes.

@lambdageek
Copy link
Member

Just for my own understanding, why do we still produce and upload them to the transport feed?

I don't know if the transport feed is the best place, but the general use case for the desktop Mono runtime packs are:

  1. Allow runtime engineers to try out issues on Mono in console apps. Often this is easier than debugging and validating fixes in mobile or wasm apps.
  2. Give some sophisticated users an option to experiment with the mono hosting api on desktop platforms instead of jumping into mobile. (For basically the same reason - it's easier to debug)

@lambdageek
Copy link
Member

Related to dotnet/docs#41366

@lambdageek lambdageek added area-Build-mono and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Jul 2, 2024
@ViktorHofer
Copy link
Member

OK makes sense. So we still want the option to run MonoVM on desktop but just as a testing vehicle for runtime devs and not as a shipping product feature.

@steveisok
Copy link
Member Author

I manually ran an official build and it shows all of the desktop related mono runtime packs in the NonShipping folder.

@srxqds
Copy link
Contributor

srxqds commented Jul 3, 2024

there are so many team embed mono with game engine。
I hope you keep the original plan. upload the mono desktop runtime package.

@steveisok
Copy link
Member Author

there are so many team embed mono with game engine。 I hope you keep the original plan. upload the mono desktop runtime package.

@srxqds can you reply in dotnet/docs#41366 and describe your scenario?

@steveisok steveisok added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Jul 3, 2024
@steveisok
Copy link
Member Author

This should land after P6 snaps

@steveisok steveisok removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Jul 26, 2024
@steveisok
Copy link
Member Author

One more trip around the CI world and this is ready to go.

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

Successfully merging this pull request may close these issues.

4 participants