use VS version as base for insertion packages #4463
Conversation
setup/FSharp.Setup.props
Outdated
There was a problem hiding this comment.
I don't see $(FSharpProductVersion) referenced anywhere?
There was a problem hiding this comment.
It's used in setp\fsharp-setup-build.proj and passed through to setup\Swix\Microsoft.FSharp.Dependencies\Microsoft.FSharp.Dependencies.swixproj.
There was a problem hiding this comment.
That appears to be passing FSharpPackageVersion, not FSharpProductVersion -
https://github.com/Microsoft/visualfsharp/blob/master/setup/fsharp-setup-build.proj#L48
There was a problem hiding this comment.
Sorry, I missed a step. 3 lines below this change <FSharpPackageVersion> is set using $(FSharpProductVersion) as its prefix.
There was a problem hiding this comment.
Oh, I missed that too. Just to be complete - where are the other versions compiler, language, FSharp.Core, etc specified to be sure that they aren't also changing?
3 participants
It was recently discovered that the packages inserted into the official Visual Studio build are all prefixed with
10.1as per #4112. During the course of normal VS branch merges this can cause a state where a VS branch might actually attempt to 'downgrade' (see below) the F# package version which would cause the install builder to choose the incorrect 'newer' version.The fix is to use the Visual Studio version numbers as the prefix for the insertion packages. FSharp.Core is still versioned as 4.x, fsc is still versioned as 10.x, the language service VSIX is still versioned as 15.x, and now the internal installer packages are 15.x.
downgrade: If the
10.1prefix is not changed, thedev15.6branch might produce an insertion package with the version10.1.20180307.0and the previous day'sdev15.7branch produced10.1.20180306.0. Technically, the build fromdev15.7appears to be 'older' than thedev15.6build, even though that's not necessarily the case. As soon as thedev15.7branch is in lockdown,masterwill change this value to15.8to prepare for the next release.