FSharp.Core.dll shows product version (AssemblyInformationalVersion) as beta

[abelbraaksma]

The NuGet version of FSharp.Code.dll 4.7.0 shows that it is a beta version:

I assume that is by accident. I am not sure how the rest of the version info here should be interpreted, my guess would be it is some build number or so. In text, the full version is: 4.7.0-beta.19402.8+dbdca013b44800cbea7485946abe10c3e0e21036

The assembly info shows this in Reflector (see AssemblyInformationalVersion):

// Assembly FSharp.Core, Version 4.7.0.0

[assembly: AssemblyFlags(AssemblyNameFlags.EnableJITcompileTracking | AssemblyNameFlags.PublicKey)]
[assembly: FSharpInterfaceDataVersion(2, 0, 0)]
[assembly: TargetFramework(".NETFramework,Version=v4.5", FrameworkDisplayName=".NET Framework 4.5")]
[assembly: AssemblyCompany("Microsoft Corporation")]
[assembly: AssemblyConfiguration("Release")]
[assembly: AssemblyCopyright("\x00a9 Microsoft Corporation. All rights reserved.")]
[assembly: AssemblyFileVersion("4.700.19.40208")]
[assembly: AssemblyInformationalVersion("4.7.0-beta.19402.8+dbdca013b44800cbea7485946abe10c3e0e21036")]
[assembly: AssemblyProduct("FSharp.Core")]
[assembly: AssemblyTitle("FSharp.Core")]
[assembly: AssemblyVersion("4.7.0.0")]
[assembly: NeutralResourcesLanguage("en-US")]

[cartermp]

This is by design, a consequence of how tooling surfaces and VS while also being allowed to update independently of the entire unit (e.g., nightly builds). You'll notice that the same is one with C#/VB here:

[abelbraaksma]

@cartermp, but isn't that very confusing? Any production-ready version of the libraries oughtn't having 'beta' in their string, right?

And your screenshot is of VS 16.5 (edit: not sure, sorry, thought so), which is preview, in which case this seems normal. My point was with the libs that are considered RTM.

[cartermp]

'tis how it works with VS, unfortunately. We either do this across the board to support loading a newer VSIX independently of the VS ship cycle or we disallow things like nightlies.

[jmarolf]

The issue is how do we know what the final build is going to be? Today the version number is baked in at build time. Presumably we could enact a process that escrow insertions into VS all have the beta tag stripped from them but this is a general github.com/dotnet engineering process that not been worked out yet

[abelbraaksma]

@jmarolf, thanks for chiming in. I have to say that it sounds rather odd that this is an accepted situation, and when I saw it first it really struck me and was under the impression I was shipping with beta versions.

how do we know what the final build is going to be?

Is it really that hard to solve? Typically, anything RTM is tagged in a branch one way or the other, and we already take info from the github repo into the build. One solution would be to consistently add a label 'beta', 'rtm', 'preview', which has the advantage of being informative in github as well.

I understand it's work, esp to do this company wide, but the alternative is shipping products with 'beta' in their names when checking the product properties. Surely that can't be the intention? And if 'beta' has no meaning anyway, perhaps just drop it completely as a quick fix?

[cartermp]

Is it really that hard to solve?

Yep.

[jmarolf]

I am not saying its hard to solve, just that it hasn't been yet. This seems like a good issue to track that work

[abelbraaksma]

@jmarolf, that sounds great! Maybe you can reopen the issue?