FCS needs to build against stable public FSharp.Core package

[dsyme]

I'm trying to use FSharp.Compiler.Service 38.0.1-beta.20607.1 from our nuget feed and am getting this:

 FSharp.Compiler.Service 38.0.1-beta.20607.1 requested package FSharp.Core: 5.0.1-beta.20607.1 (beta)*

This is because FSharp.Compiler.Service is currently being built against latest in-branch FSharp.Core on the CI feed

I believe we should simply stop building against the in-repo FSharp.Core at all (though we can test against it in test projects) and always build against a stable, known, public FSharp.Core like 4.7.2 or 5.0.0. This has many benefits

1. makes it possible to use latest nuget packages from our nuget feed without picking up a dependency on a beta FSharp.Core
2. increase the reach of the whole FCS ecosystem

[dsyme]

@cartermp @KevinRansom @brettfo It feels like our decision to have the official dotnet/fsharp builds publish FCS nuget means it's become a bit of a choke point.

For example #10575 went in 22 days ago but now the community aren't empowered to push out an official FCS update.

I know the tradeoffs - having official builds aligned to release branches, published and signed, is great long term. However fsdocs remains unusable on .NET 5.0 after a month or more since we identified and fixed the issue (fsprojects/FSharp.Formatting#621) - that's quite disempowering for the community side of things, and it chokes out the entire uptake of net50 in the broader ecosystem

How can we improve things to get more point releases out to nuget.org? I don't mind if they are labelled beta (though I'd prefer not). But they really do need to be without the FSharp.Core beta dependency.

Previously when a fix went into FSharp.Compiler.Service it was often rolled out to the whole ecosystem (including Ionide) within a day or two. When updates are slower this has the other effect - people are strongly disincentivized to fix things "at the core" and end up layering hack upon hack over the top of FCS.

[Krzysztof-Cieslak]

1. When @baronfel was managing FCS repo and releases, the package was always depending on stable FSharp.Core - not sure why this would change here
2. We definitely need faster release cycle on FCS package - it's been over a month since .NET 5 release and we still can't fix #r dependency issues as 38.0.1 is frozen for some reasons. Not to mention fixes like Fix FSharpNavigationDeclarationItem for ValField #10727 for which I don't even have a timeline

[cartermp]

We should build against 5.0.0 but not earlier. It makes no sense to me - at all - why we would ever want to hamstring the F# compiler API to be several F# versions back when it is literally built against the current F# version.

The real solution to your problem is for us to just release FCS. This unfortunately requires someone at Microsoft to check their inbox after they changed the policy for nuget to allow things to ship.

[KevinRansom]

@Krzysztof-Cieslak
the Fcs package release is stuck in limbo because we have signing validation issues ... and it's Holiday season so people are not reliably available.

As for buiilding against a stable FSharp.Core, since FCS dependes on the compiler, and a big chunk of the compiler is in fsharp.core we took the view it would always be prudent to locally build against the latest preview here.
Of course releases to nuget will be against a nuget released FSharp.Core, and preview releases of FCS against a preview released FSharp.Core.

[cartermp]

FYI I have pinged more people to see who checks the inbox, since it's a little ridiculous

[KevinRansom]

@cartermp , thanks mate ... I appreciate it.

[Krzysztof-Cieslak]

the Fcs package release is stuck in limbo because we have signing validation issues ... and it's Holiday season so people are not reliably available.

Yes, that's a great example of what's happening when the community gives away its power to MSFT - we had a flawed, but at least working process with multiple owners of the NuGet package and repository that we used to do a quick rollout of the features and bugfixes when necessary.

Now, we can't get a fix because it's the holiday season.

[cartermp]

Yes, it sucks, we know. If they hadn't changed the rules for nuget publishing and/or if we didn't find out about that until pretty much the holidays things would be different, but they're not. Sorry about that. Hopefully it resolves soon and we'll be back to a normal working order.

@Krzysztof-Cieslak If you really need a fix for the dependency manager out right now, you can either depend on the public preview of the package, which is available for use by your feeds already since it's public + you have the right feed (and the right version number), or set up a temporary package. It's been available ever since version 38 was cut in our build.

[cartermp]

Closing out as the core issue of not having the nuget dependency manager included in FCS is resolved