use VS version as base for insertion packages #4463
Merged
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.
It was recently discovered that the packages inserted into the official Visual Studio build are all prefixed with
10.1
as 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.1
prefix is not changed, thedev15.6
branch might produce an insertion package with the version10.1.20180307.0
and the previous day'sdev15.7
branch produced10.1.20180306.0
. Technically, the build fromdev15.7
appears to be 'older' than thedev15.6
build, even though that's not necessarily the case. As soon as thedev15.7
branch is in lockdown,master
will change this value to15.8
to prepare for the next release.