Mark Aspire.Hosting.Python as experimental

[sebastienros]

Description

Fixes #6298

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue:
  • No

Microsoft Reviewers: Open in CodeFlow

[davidfowl]

We want to mark the API as experimental. When you call AddPythonApp it should have the attribute on it. Like this https://github.com/eerhardt/aspire/blob/5603e928797a629d972c0084e2d6414169d1295c/src/Aspire.Hosting.Azure.CognitiveServices/AzureOpenAIExtensions.cs#L39

[davidfowl]

Although, maybe pre-release is enough to signal what we want.

[sebastienros]

I could not find this attribute used anywhere though.

Update: not saying we shouldn't use it, but all the experimental stuff we have is based on the package version only from what I see. Waiting to learn more ;)

[davidfowl]

Why isn't this in the csproj?

[eerhardt]

See conversation here: #6195 (comment)

cc @joperezr

[sebastienros]

Based on this PR this is the way to do it now
https://github.com/dotnet/aspire/pull/6195/files

[joperezr]

That is no longer the case, it was only for RC1 as we had things going RC1 and some other things staying in preview, but now everything should fall back to be preview or stable.

[eerhardt]

My thoughts:

1. Making a nuget package not stable (i.e. have a -preview suffix in the version) should be enough signal to people that the API can change before it becomes stable. Users don't have to install a "pre release" package and then ALSO suppress a warning about using experimental APIs inside that prerelease package.

2. Aspire.Hosting.Python already shipped stable in 8.1 and 8.2. If we don't ship a "stable" 9.0.0 package, people will continue using the 8.2.1 Aspire.Hosting.Python package with Aspire 9.0. This maybe won't cause problems, but it will be confusing.

[davidfowl]

@DamianEdwards thoughts?

[eerhardt]

Another problem is that shipped https://www.nuget.org/packages/Aspire.Hosting.Python/9.0.0-rc.1.24511.1. Which means when we ship 9.0.0 GA, the Python package produced with that build will still have -preview and will be LOWER than the rc1 package. So even if people move to the 9.0.* package, they will get the rc1 package, which is old.

Maybe we need to ship this as stable and mark the APIs as [Experimental]....

[DamianEdwards]

Maybe we need to ship this as stable and mark the APIs as [Experimental]....

I thought that was the proposal?

[eerhardt]

Maybe we need to ship this as stable and mark the APIs as [Experimental]....

I thought that was the proposal?

What ended up getting changed was the package is no longer building as "stable", so when it gets built it will have a -preview version.

[sebastienros]

I will do the change