| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Dongbo Wang (@daxian-dbw) Commit to get PS version from Git is ready. If you want I can add it to the PR. It is only add one new Target. |
Sorry, something went wrong.
|
Ilya (@iSazonov) If the new Target is not huge then add it in and let's review it together. |
Sorry, something went wrong.
|
The new target is very simple. Also I tried to build a package by Start-PSBuild -Clean -CrossGen -Runtime win10-x64 -Configuration Release
Start-PSPackage -Type msiand got PowerShell-6.0.0-beta.3-win10-win2016-x64.msi. |
Sorry, something went wrong.
|
It's good that you verified the package generation. But it's the NuGet package that I'm worried. Without <VersionPrefix>6.0.0</VersionPrefix>, you will get NuGet packages with 1.0.0 in the name. |
Sorry, something went wrong.
|
How can I build the NuGet package? |
Sorry, something went wrong.
|
Ilya (@iSazonov) see document here: https://github.com/PowerShell/PowerShell/blob/master/docs/maintainers/releasing.md#nuget-packages |
Sorry, something went wrong.
| <PS6AdditionalCommits>$([System.Text.RegularExpressions.Regex]::Match($(PowerShellVersion), $(RegexGitVersion)).Groups[2].Value)</PS6AdditionalCommits> | ||
| <PS6CommitSHA>$([System.Text.RegularExpressions.Regex]::Match($(PowerShellVersion), $(RegexGitVersion)).Groups[3].Value)</PS6CommitSHA> | ||
|
|
||
| <RegexSymVer>^(\d+).(\d+).(\d+)-(.+)</RegexSymVer> |
There was a problem hiding this comment.
This regular expression will fail when we finally reach the official v6.0.0 (no -beta.N part anymore).
Sorry, something went wrong.
There was a problem hiding this comment.
No plans -rtm?
In any case I can make the part as optional.
Sorry, something went wrong.
| <Output TaskParameter="ConsoleOutput" PropertyName="PowerShellVersion" /> | ||
| </Exec> | ||
|
|
||
| <PropertyGroup> |
There was a problem hiding this comment.
The whole <PropertyGroup> block should be indented since it's part of the <Target>
Sorry, something went wrong.
There was a problem hiding this comment.
We reverted the commit.
Sorry, something went wrong.
| <PS6PatchVersion>$([System.Text.RegularExpressions.Regex]::Match($(PS6BuildVersion), $(RegexSymVer)).Groups[3].Value)</PS6PatchVersion> | ||
| <PS6LabelVersion>$([System.Text.RegularExpressions.Regex]::Match($(PS6BuildVersion), $(RegexSymVer)).Groups[4].Value)</PS6LabelVersion> | ||
|
|
||
| <PS6FormattedVersion Condition="'$(PS6AdditionalCommits)' == ''">$(PS6BuildVersion) SHA: $(PS6CommitSHA)</PS6FormattedVersion> |
There was a problem hiding this comment.
I think $(PS6AdditionalCommits) will never be an empty string, because when there is no additional commit, it should be 0.
Sorry, something went wrong.
There was a problem hiding this comment.
Good catch!
Will fix in next PR.
Sorry, something went wrong.
| <AssemblyVersion>6.0.0.0</AssemblyVersion> | ||
|
|
||
| <ProductVersion>6.0.0-beta.3</ProductVersion> | ||
| <InformationalVersion>6.0.0-beta.3</InformationalVersion> |
There was a problem hiding this comment.
I guess you don't need to hard code them now?
Sorry, something went wrong.
There was a problem hiding this comment.
The commit was reverted.
Sorry, something went wrong.
| <GitInfoBaseDir Condition="'$(GitInfoBaseDir)' == ''">$(MSBuildProjectDirectory)/$(GitCDUP)/.git</GitInfoBaseDir> | ||
| </PropertyGroup> | ||
|
|
||
| <Exec Command='$(GitExe) --git-dir="$(GitInfoBaseDir)" describe --abbrev=60 --long' ConsoleToMSBuild="true"> |
There was a problem hiding this comment.
with --long, even if it's right on a tag, you still will get the long version like v6.0.0-beta.3-0-gxxxxxxxxx. However, when we are right on a tag, we are expecting the GitCommitId to be v6.0.0-beta.3.
Sorry, something went wrong.
|
|
||
| <ProductVersion>$(PS6BuildVersion)</ProductVersion> | ||
| <!-- PackageVersion>$(PS6BuildVersion)</PackageVersion --> | ||
| <InformationalVersion>$(PS6FormattedVersion)</InformationalVersion> |
There was a problem hiding this comment.
This is what I get from Microsoft.Win32.Registry.AccessControl.dll:
PS:156> $o | fl ProductVersion, FileVersion, FileName, ProductName ProductVersion : 4.6.25428.01 built by: dlab-DDVSOWINAGE031. Commit Hash: 644b3ba1fec90828fc31353461b7d1a4aac7ea7f FileVersion : 4.6.25428.01 FileName : C:\Users\dongbow\Downloads\Microsoft.Win32.Registry.AccessControl.dll ProductName : Microsoft® .NET Framework
AssemblyInformationalVersion maps to ProductVersion, while AssemblyFileVersion maps to FileVersion, maybe we should do similar thing in powershell assemblies.
Sorry, something went wrong.
| [assembly: AssemblyVersion("3.0.0.0")] | ||
|
|
||
| [assembly: AssemblyCulture("")] | ||
| [assembly: NeutralResourcesLanguage("en-US")] |
There was a problem hiding this comment.
I don't think [assembly: AssemblyCulture("")] is necessary. We can remove it.
As for [assembly: NeutralResourcesLanguage("en-US")] it can be replaced by <NeutralLanguage>en-US</NeutralLanguage> in csproj, and I think this tag can go in PowerShell.Common.props
Sorry, something went wrong.
There was a problem hiding this comment.
Done.
Sorry, something went wrong.
| [assembly: AssemblyVersion("3.0.0.0")] | ||
|
|
||
| [assembly: AssemblyCulture("")] | ||
| [assembly: NeutralResourcesLanguage("en-US")] |
There was a problem hiding this comment.
Same here and in other files. So for this one, the AssemlbyInfo.cs file can be deleted probably.
Sorry, something went wrong.
There was a problem hiding this comment.
The some AssemlbyInfo.cs files is empty now.
What is the probability that we will not add personal attributes?
Sorry, something went wrong.
|
Get the tag commit meta info from the target is good, but it raises a problem -- in our release process, we need to be able to build and package powershell core targeting a tag label, say v6.0.0-beta.4, without actually creating the tag. We added a new parameter -ReleaseTag to Start-PSBuild and Start-PSPackage so that currently we can build and package powershell without a tag but still have the correct $PSVersionTable.GitCommitId. (see https://github.com/PowerShell/PowerShell/blob/master/docs/maintainers/releasing.md#release-steps for more information) However, with this taget change, the FileVersion, ProductVersion won't be correct without the tag being pushed, so it will break our release process. The reason to create the tag until finishing preparing the release is that issues may come up when or after build/package, and in that case we need check in fixes. If tag is already pushed, then it's super hard to do the fix. Given this, I suggest to separate the GetPS6VersionFromGit target out from this PR, let's get the common.props part in first. |
Sorry, something went wrong.
|
@PowerShell/powershell-committee reviewed this and is fine with taking the assembly version to 6.0.0 and taking it now to discover customer impact |
Sorry, something went wrong.
|
Steve Lee (@SteveL-MSFT) Could we add @PowerShell/powershell-committee argumentations to the PR description if in future customers catch any problems with the change? Also my question is - what is a best practice to ensure assembly backward compatibility? If we follow the best practice, we can recommend the same users to avoid the problem. Dongbo Wang (@daxian-dbw) Well, I revert last commit. We can easy pass a ReleaseTag value by ```dotnet build ... /p:"PS6BuildVersion=$ReleaseTag" in Build.psm1. I'll add this in next PR. |
Sorry, something went wrong.
Thanks Ilya (@iSazonov)! Appreciate your quick action. |
Sorry, something went wrong.
| <NeutralLanguage>en-US</NeutralLanguage> | ||
|
|
||
| <ProductVersion>6.0.0-beta.3</ProductVersion> | ||
| <InformationalVersion>6.0.0-beta.3</InformationalVersion> |
There was a problem hiding this comment.
I think <ProductVersion> and InformationalVersion are probably not needed in this PR. The target change can bring them back.
Sorry, something went wrong.
There was a problem hiding this comment.
Removed.
Sorry, something went wrong.
|
|
||
| <FileVersion>6.0.0.0</FileVersion> | ||
| <AssemblyVersion>6.0.0.0</AssemblyVersion> | ||
| <NeutralLanguage>en-US</NeutralLanguage> |
There was a problem hiding this comment.
I think we need the <VersionPrefix>6.0.0</VersionPrefix> to represent the project version, so that the NuGet package versions are correct.
Sorry, something went wrong.
There was a problem hiding this comment.
I agree.
Done.
For clarify. I only found the VersionPrefix in Microsoft.NET.DefaultAssemblyInfo.targets where it define Version property.
Sorry, something went wrong.
There was a problem hiding this comment.
Currently, Version composition works as this: If Version is unset, use VersionPrefix (defaults to 1.0.0 if unset) and - if present - append VersionSuffix.
All other version are then defaulted to whatever Version is.
Quoted from StackOverflow
Sorry, something went wrong.
There was a problem hiding this comment.
AssemblyVersion and FileVesion are inferred by Version by default. But if they are set, it is considered an override of the default inference.
Not only these 2 versions, ProductVersion and InformationalVersion are also inferred from Version if they are not set. (and ProductVersion is by default the same as InformationVersion)
Sorry, something went wrong.
| @@ -1,9 +1,2 @@ | |||
| using System.Reflection; | |||
| using System.Resources; | |||
There was a problem hiding this comment.
We probably can remove this file now.
Sorry, something went wrong.
There was a problem hiding this comment.
Done.
Sorry, something went wrong.
| <SignAssembly>true</SignAssembly> | ||
| <GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute> | ||
| <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute> | ||
| <GenerateNeutralResourcesLanguageAttribute>false</GenerateNeutralResourcesLanguageAttribute> |
There was a problem hiding this comment.
<GenerateNeutralResourcesLanguageAttribute> should be removed now.
Sorry, something went wrong.
There was a problem hiding this comment.
Done.
Sorry, something went wrong.
| @@ -1,8 +1,2 @@ | |||
| using System.Reflection; | |||
| using System.Resources; | |||
There was a problem hiding this comment.
This file can be removed now.
Sorry, something went wrong.
There was a problem hiding this comment.
Done.
Sorry, something went wrong.
| <NoWarn>$(NoWarn);CS1570</NoWarn> | ||
| <TreatWarningsAsErrors>true</TreatWarningsAsErrors> | ||
| <AllowUnsafeBlocks>true</AllowUnsafeBlocks> | ||
| <DelaySign>true</DelaySign> |
There was a problem hiding this comment.
This tag is now needed now.
Sorry, something went wrong.
There was a problem hiding this comment.
Sorry?
Sorry, something went wrong.
There was a problem hiding this comment.
not needed now 😄
Sorry, something went wrong.
There was a problem hiding this comment.
Removed.
Sorry, something went wrong.
| <SignAssembly>true</SignAssembly> | ||
| <GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute> | ||
| <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute> | ||
| <GenerateNeutralResourcesLanguageAttribute>false</GenerateNeutralResourcesLanguageAttribute> |
There was a problem hiding this comment.
This tag can be removed now.
Sorry, something went wrong.
There was a problem hiding this comment.
Done.
Sorry, something went wrong.
| @@ -1,4 +1 @@ | |||
| using System.Reflection; | |||
There was a problem hiding this comment.
This file can be removed now.
Sorry, something went wrong.
There was a problem hiding this comment.
Done.
Sorry, something went wrong.
| @@ -1,4 +1 @@ | |||
| using System.Reflection; | |||
There was a problem hiding this comment.
This file can be removed now.
Sorry, something went wrong.
There was a problem hiding this comment.
Done.
Sorry, something went wrong.
| <SignAssembly>true</SignAssembly> | ||
| <GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute> | ||
| <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute> | ||
| <GenerateNeutralResourcesLanguageAttribute>false</GenerateNeutralResourcesLanguageAttribute> |
There was a problem hiding this comment.
This tag can be removed now.
Sorry, something went wrong.
There was a problem hiding this comment.
Done.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM. Ilya (@iSazonov) Thanks for your hard work on this and your patience as well.
Sorry, something went wrong.
|
Dongbo Wang (@daxian-dbw) Thanks for review! I am ready to continue the work in new PR. |
Sorry, something went wrong.
…werShell.Common.props' (PowerShell#4106) `AssemblyVersion` and `FileVersion` are now inferred from the `Version` property, which is inferred by `VersionPrefix`. So now both `AssemblyVersion` and `FileVersion` are 6.0.0.0 for each of PowerShell assemblies, and the `ProductVersion` and `InformationalVersion` are 6.0.0.
| Back | FazBrowse Home | New Git URL |
Reopen #3917
Related #3400
Motivation
We inherited old assembly file versions from Windows PowerShell.
Currently we shouldn't set versions of assemblies statically in AssemblyInfo.cs files, we should set versions of assemblies dynamically by MSBuild as discussed in #3690.
Fix
Follow-Up Work
In the PR we temporarily hard code assembly versions as "6.0.0-beta.3".
Later we should set a dll version based on GitCommitId.
Additional considerations
In previous PR #3917 we caught some problems and we should fix it here:
Note
Quoted from Steve Lee (@SteveL-MSFT):