-
Notifications
You must be signed in to change notification settings - Fork 790
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
FCS needs to build against stable public FSharp.Core package #10778
Comments
@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 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. |
|
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. |
@Krzysztof-Cieslak 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. |
FYI I have pinged more people to see who checks the inbox, since it's a little ridiculous |
@cartermp , thanks mate ... I appreciate it. |
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. |
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. |
Closing out as the core issue of not having the nuget dependency manager included in FCS is resolved |
I'm trying to use FSharp.Compiler.Service 38.0.1-beta.20607.1 from our nuget feed and am getting this:
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
The text was updated successfully, but these errors were encountered: