[release/6.0] Don't special case "Experimental" projects #60643
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
We only have one experimental project, System.Runtime.Experimental and we want it to behave like any other package.
|
Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer |
ghost
added this to In Progress
in 
|
Interesting, this is failing only in release/6.0: Due to Do we know what the intent is for ILCompiler.Reflection.ReadyToRun.Experimental? @cshung @MichalStrehovsky |
|
IMHO I think we should leave the logic for Experimental packages as it was and then if a specific experimental package that we want it to make it to NuGet.org and stabilized, should override these properties on the project file directly. We have gone back and forth removing this and bringing it back because sometimes we want to ship some and sometimes we don't but the consensus we made for 5.0 was that the experimental packages in dotnet/runtime usually don't ship stable and don't ship to NuGet (of course this was before dotnet/runtimelab, so that might change the perspective). |
|
The fact that we go back and forth so much means that there's probably no grounds for a name-based convention. Why not make folks call it out explicitly? The problem here is that there were two places that were trying to capture this behavior and they got out of sync. Can we just make the project's set IsShipping to declare their behavior? |
Sure they would need to set IsShippingPackage=false and SuppressFinalPackageVersion=true in the package if we want this to be opt-in rather than opt-out. But I see that, there is yet another package: I believe |
|
I think for 6.0 we should just |
|
I think some of this thinking changed since 5.0, since we added the ability to ship experimental functionality in the product. I'm OK with whatever folks decide to unblock the build. I pushed another commit which I think cleans up the naming conventions in coreclr. Feel free to merge or close this PR. I submitted to try to help unblock 6.0 stabalization. |
|
Thanks, @ericstj I was just adding my 2c, but yeah I do agree that the thinking changed after 5.0. I'm fine with how the change is now. We just need to make sure to remember that if or some reason we add an Experimental package that we don't want to ship to NuGet at some point on 7 an onwards, to set the properties accordingly on that project. |
|
Just wanted to make sure - ILCompiler.Reflection.ReadyToRun.Experimental will not end up on NuGet.org, is that correct? We don't have any versioning/security/etc. guarantees around this package. This package is shipped as-is for ILSpy to consume and the expectations communicated there. See #41379. |
Yes that is correct, that is one of the things the false flag indicates. |
Backport of #60641 to release/6.0
/cc @ericstj
Infra change to build Experimental projects with correct version.