-
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
fix16014 - Update package versions for fsharp.core and fsharp.compiler.service #16015
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Shouldn't this go to 17.7 branch? Since we don't insert main, and 17.8 has its own versioning. |
yes |
KevinRansom
force-pushed
the
updateto402
branch
from
September 21, 2023 19:47
fe2dd79
to
790c2a7
Compare
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
Please, don't rerun pipelines, 3 cancelled (failing) tasks are the ones in main and not in 17.7, they will not be running here. We should just ignore them. |
Is this ready to go then? |
vzarytovskii
approved these changes
Sep 22, 2023
dawedawe
added a commit
to dawedawe/FSharp.Analyzers.SDK
that referenced
this pull request
Sep 26, 2023
dawedawe
added a commit
to G-Research/fsharp-analyzers
that referenced
this pull request
Sep 26, 2023
dawedawe
added a commit
to G-Research/fsharp-analyzers
that referenced
this pull request
Sep 26, 2023
* remove packages.lock.json files till we have a fixed sdk see dotnet/fsharp#16014 and dotnet/fsharp#16015 * set RestorePackagesWithLockFile and RestoreLockedMode to false in Directory.Build.props remove doubled RestorePackagesWithLockFile entry in Directory.Packages.props * adjust to latest master in SDK * Revert "adjust to latest master in SDK" This reverts commit a4b635e. * switch to the package references * remove build of SDK from ci.yml
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix #16014 FSharp.Core package versions aren't incrementing with each SDK release
We have failed to update the compiler service and fsharp.core releases to match sdk releases.
Description
When the dotnet sdk ships and releases it includes an updated FSharp Compiler and FSharp.Core nuget package. The latest release of the dotnet sdk 7.0.401 includes updated compilers and cores, however, the nuget package version was not updated, ordinarily this is not a significant issue, however, the SDK also includes an embedded fsharp.core nuget package, this enables fsharp builds to succeed offline from nuget. This behaviour works well, however, when using nuget lock files the hash of the nuget package in SDK 7.0.401, differs from that shipped with sdk 7.0.400 and shipped to nuget. Which means that developers using nuget lock files get a warning message during build.
Regression? yes
Risk: very low
Original issue: #16014 - FSharp.Core package versions aren't incrementing with each SDK release.
The impacted nuget packages: FSharp.Compiler.Service and FSharp.Core are shipped automatically as part of the SDK release process
How to prevent this moving forward: it is quite tough to figure out how to prevent this, because in fact the version number had been changed in our branch (I.e. we remembered to make the necessary change) ... but the change didn't flow to the Sdk repo. We are considering an automatic tool to update it and ensure we push it into the sdk