Remove date number from dev build version #1835

dagood · 2020-01-16T22:12:21Z

safern · 2020-01-16T22:16:01Z

eng/Versions.props

@@ -6,8 +6,6 @@
    <MajorVersion>5</MajorVersion>
    <MinorVersion>0</MinorVersion>
    <PatchVersion>0</PatchVersion>
-    <!-- Always use shipping version instead of dummy version -->
-    <DotNetUseShippingVersions>true</DotNetUseShippingVersions>


Can we leave this set to true when we're in an Official build? So that package versions are unique?

Not necessary. https://github.com/dotnet/arcade/blob/bca68c2df2c6230389f10def3880a61db266c6c1/src/Microsoft.DotNet.Arcade.Sdk/tools/Version.BeforeCommonTargets.targets#L39

Awesome, arcade is ahead of me 😄

dagood · 2020-01-16T22:52:32Z

Getting errors in Libraries build--a lot of these:

.packages\microsoft.dotnet.build.tasks.packaging\5.0.0-beta.20063.2\build\Packaging.targets(1161,5): error : File Microsoft.Win32.Primitives, version 42.42.42.42 was included framework package Microsoft.Private.CoreFx.NETCoreApp/5.0.0-ci but that version is not considered inbox in package index F:\workspace_work\1\s\src\libraries\pkg\Microsoft.Private.PackageBaseline\packageIndex.json. Please add it with appropriate InboxOn entry for netcoreapp5.0 or suppress this message with PermitInbox suppression.

safern · 2020-01-16T23:10:20Z

Getting errors in Libraries build--a lot of these:

Yeah, the assembly version was affected by this change and now it is getting arcade's 42.42.42.42 version... we need to figure out how to set it up so that it respects our AssemblyVersions.

dagood · 2020-01-16T23:13:20Z

Might be tricky, getting Arcade to produce date-based assembly versions but not use the date for the packages. Maybe condition DotNetUseShippingVersions so it's specifically on during certain parts of the build? Don't know if that'll work out.

Feel free to push to this PR if you have time to work on it (or make a new one, no real difference).

dagood · 2020-01-16T23:16:25Z

An alternative that fixes CI (but not dev build annoyances) is to pipe in a "non-official officialbuildid" so the date number stays constant throughout the course of the CI run.

safern · 2020-01-16T23:44:33Z

We could also introduce an arcade property... something like UseAssemblyShippingVersions.

safern · 2020-01-16T23:44:49Z

cc: @tmat @mmitche for discussion.

safern · 2020-01-17T00:44:43Z

We could also introduce an arcade property... something like UseAssemblyShippingVersions.

Never mind I think we figured out the issue.

dagood · 2020-01-17T00:50:13Z

src/libraries/Directory.Build.props

@@ -4,6 +4,10 @@
  </PropertyGroup>
  <Import Project="..\..\Directory.Build.props" />

+  <PropertyGroup>
+    <AssemblyVersion>5.0.0.0</AssemblyVersion>


This matches https://github.com/dotnet/corefx/pull/41723/files#diff-8b8f08ffbf7b863fb3700c1718eeb4cbR5, we should maybe use ProductVersion or Major/Minor/PatchVersion though.

cc: @ericstj I think it makes sense to use any of the recommendations above.

Yes, we should not have the version specified in multiple places.
I'd use <AssemblyVersion>$(MajorVersion).$(MinorVersion).$(PatchVersion).0</AssemblyVersion> if you want to suppress defaulting to 42.42.42.42.

I'd be also nice to add a comment that explains why is this set here - something like (guessing) "The AssemblyVersion must match netcoreappM.N moniker. Whenever the version is updated we need to update the TFM as well.".

dagood · 2020-01-17T00:54:20Z

An alternative that fixes CI (but not dev build annoyances) is to pipe in a "non-official officialbuildid" so the date number stays constant throughout the course of the CI run.

To expand on this a bit (in case the assembly version fix doesn't work, or maybe something else breaks downstream), maybe we can keep DotNetUseShippingVersions as true, but set /p:_BuildNumber=$(BUILD_BUILDNUMBER) so that the version stays constant across the jobs.

safern · 2020-01-17T00:59:05Z

That might be a good idea, the problem I see with that is that it doesn't solve the local live live issue of people having to rebuild libraries/coreclr if they want to build again the installer a day after they built libraries or coreclr.

safern · 2020-01-17T03:02:40Z

It seems like the dependency to System.Private.CoreLib has the wrong version, I don't know if CoreLib also needs to be 5.0.0.0 or if we're calculating the dependency wrong. @ericstj might know.

C:\h\w\98B8088C\p\packageTest.targets(74,5): error : Assembly 'System.Runtime.Intrinsics.Experimental' has insufficient version for dependency 'System.Private.CoreLib' : 5.0.0.0 < 42.42.42.42. [C:\h\w\98B8088C\w\A0E70914\u\netcoreapp5.0\project.csproj]

mmitche · 2020-01-17T15:05:49Z

What's the context here? I think I'm missing what the root of the issue is.

dagood · 2020-01-17T16:47:29Z

See #1089

tmat · 2020-01-20T21:12:41Z

@dagood Are there any customizations to versioning in dotnet/runtime repo that tweak the default Arcade versions or are there any parts of the repo that use something different than the versions Arcade sets? I don't see how PR validation spanning a day boundary could be a problem if the whole build used $(OfficialBuildId) to derive version numbers (which happens to be a date based number, but that's not a requirement). The build should not depend on current time in any way. If there is some part of the build that depends on current date/time that'd be a bug.

dagood · 2020-01-20T21:52:59Z

I don't see how PR validation spanning a day boundary could be a problem if the whole build used $(OfficialBuildId) to derive version numbers (which happens to be a date based number, but that's not a requirement).

PR builds are not official builds, so we don't use OfficialBuildId. The Arcade docs include this guidance: Versioning.md#build-kind.

However, this is basically the same as my suggestion to set /p:_BuildNumber=$(BUILD_BUILDNUMBER).

dagood · 2020-01-20T21:57:42Z

As for why we have this issue:

it doesn't solve the local live live issue of people having to rebuild libraries/coreclr if they want to build again the installer a day after they built libraries or coreclr.

It's because dotnet/runtime sets <DotNetUseShippingVersions>true</DotNetUseShippingVersions>.

tmat · 2020-01-21T00:01:06Z

PR builds are not official builds, so we don't use OfficialBuildId.

I see. I mistaken this for official build issue. Got it. In PR validation though the version has Major.Minor.Path-ci format. No date based version number is added.

However, this is basically the same as my suggestion to set /p:_BuildNumber=$(BUILD_BUILDNUMBER).

I would rather avoid that. _BuildNumber is a private property not to be used outside of Arcade SDK targets.

tmat · 2020-01-21T00:02:15Z

It's because dotnet/runtime sets <DotNetUseShippingVersions>true</DotNetUseShippingVersions>.

Now I understand. Yes, don't set this.

dagood · 2020-01-21T02:07:37Z

You don't have to tell me. 😄

safern · 2020-01-21T17:55:00Z

I think we just need to figure out why we're getting the package test failures. I agree we shouldn't set DotNetUseShippingVersions. I'll take a look locally to see if I get a repro and a suggested fix.

dagood · 2020-01-21T18:04:56Z

Please feel free to push to this PR or make your own, I'm not actively working on this.

safern · 2020-01-22T01:42:13Z

@dagood I moved the AssemblyVersion declaration to Versions.props and also, I made it use $(MajorVersion).$(MinorVersion).0.0 -- as for the patches and revisions should be manually updated per assembly if it is serviced (talked to @ericstj on this).

Also, package testing is currently using a Microsoft.NETCore.App package from our custom feeds. I updated it manually to use the latest one. I didn't want to add a BAR subscription to the runtime repo because of the ongoing discussion regarding to that and we should eventually fix package testing to use the live bits rather than the latest published bits. Will open an issue for that.

…orVersion.0.0 in the root

dagood · 2020-01-22T19:46:51Z

eng/Versions.props

    <PreReleaseVersionLabel>alpha</PreReleaseVersionLabel>
    <PreReleaseVersionIteration>1</PreReleaseVersionIteration>
+
+    <!-- Set assembly version to align with Major and Minor version -->


Also mention this? My first thought looking at this line is why it doesn't use patch version.

as for the patches and revisions should be manually updated per assembly if it is serviced

Sure. will update the comment.

dagood · 2020-01-22T19:50:48Z

eng/Versions.props

@@ -43,7 +44,7 @@
    <MicrosoftDotNetRemoteExecutorVersion>5.0.0-beta.20063.2</MicrosoftDotNetRemoteExecutorVersion>
    <MicrosoftDotNetVersionToolsTasksVersion>5.0.0-beta.20063.2</MicrosoftDotNetVersionToolsTasksVersion>
    <!-- Installer dependencies -->
-    <MicrosoftNETCoreAppVersion>5.0.0-alpha.1.19562.8</MicrosoftNETCoreAppVersion>
+    <MicrosoftNETCoreAppVersion>5.0.0-alpha.1.20071.1</MicrosoftNETCoreAppVersion>


I'm concerned that this version is being used... the installer tests need to be running on the current build's outputs or else they aren't covering anything. 😕 Can you link the issue you mentioned you'd file for this?

I'm surprised the installer tests use this property, I thought this property was used by package testing only.

I mentioned it here:
#1823 (comment)

Could you elaborate how the installer tests use this instead of the recently built product?

Could you elaborate how the installer tests use this instead of the recently built product?

No, I'm not familiar with it and I'm surprised by it when you mentioned you had to change this to make the installer tests work.

I didn't mean installer tests, I mean libraries all configuration package tests... we run some tests on our oob packages to make sure closure is complete and that we don't ship duplicate types and that all supported rids for those packages publish correctly, etc.

Ah. This should be moved out from  then, it seems to me. Thanks for the background.

I see, that was a result from the repo merge as in corefx it was "core-setup dependencies" maybe when we consolidated it was just a find and replace from "core-setup" to "installer". Will remove.

Actually, what it means is that those dependencies as built by the installer. If you look the file, those comments split the sections on where are those packages coming from, for example look at runtime-assets dependencies which comes from https://github.com/dotnet/runtime-assets or arcade dependencies.

Oh, that makes sense. Sorry for the confusion on this, no need to change it.

dagood · 2020-01-23T19:02:31Z

I don't have enough context on the test expectations to help with the current CI error:

Assert.Equal() Failure
 ↓ (pos 20)
Expected: ComLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=···
Actual: ComLibrary, Version=5.0.0.0, Culture=neutral, PublicKeyToken=···
 ↑ (pos 20)

   at Microsoft.NET.HostModel.ComHost.Tests.ClsidMapTests.PublicComVisibleTypeWithGuidAdded() in /_/src/installer/test/Microsoft.NET.HostModel.Tests/Microsoft.NET.HostModel.ComHost.Tests/ClsidMapTests.cs:line 35

Maybe @vitek-karas and @elinor-fung can help?

safern · 2020-01-23T19:17:11Z

Thanks @dagood -- I'm already looking at this locally, getting a repro and then see why ComLibrary is not getting the right AssemblyVersion.

elinor-fung · 2020-01-23T19:18:22Z

The test checks creating of a file (used for COM support) with data about a library - reading the assembly metadata; it uses the output assembly of the ComLibrary project (https://github.com/dotnet/runtime/tree/master/src/installer/test/Assets/TestProjects/ComLibrary) reading the assembly metadata.

It is hard-coded to expect version 1.0.0.0, but it looks like the output of the ComLibrary test project is now 5.0.0.0? I would expect that it should have been set to 1.0.0.0 based on this though: https://github.com/dotnet/runtime/pull/1835/files#diff-dcf139fe6da30186f3ea56c8ff1a086bR10?

safern · 2020-01-23T19:20:29Z

thanks for explaining @elinor-fung 😄

It is hard-coded to expect version 1.0.0.0, but it looks like the output of the ComLibrary test project is now 5.0.0.0? I would expect that it should have been set to 1.0.0.0 based on this though: https://github.com/dotnet/runtime/pull/1835/files#diff-dcf139fe6da30186f3ea56c8ff1a086bR10?

Me too, that''s why now I'm trying this locally to figure out why it didn't honor my AssemblyVersion in the props file for the test projects.

safern · 2020-01-24T06:41:46Z

This is now ready 😄

dagood · 2020-01-24T17:22:40Z

LGTM. (Can't approve "my" PR. 🙂)

Remove date number from dev build version

9e10218

dagood added the area-Infrastructure label Jan 16, 2020

dagood self-assigned this Jan 16, 2020

dagood mentioned this pull request Jan 16, 2020

When PR validation spans a UTC day, the Installer build may fail due to a package version mismatch #1089

Closed

safern reviewed Jan 16, 2020

View reviewed changes

Set Library assembly version back to 5.0.0.0

642d09b

dagood commented Jan 17, 2020

View reviewed changes

safern mentioned this pull request Jan 17, 2020

Coalesce adjacent loops in concatenation RegexNodes #1838

Merged

dagood removed their assignment Jan 20, 2020

Merge remote-tracking branch 'dotnet/master' into rm-date

0aac40a

Use default assembly version in versions.props and fix package testing

0e70f8f

Add missed change to define AssemblyVersion to match MajorVersion.Min…

785b157

…orVersion.0.0 in the root

tmat approved these changes Jan 22, 2020

View reviewed changes

dagood commented Jan 22, 2020

View reviewed changes

safern added 2 commits January 22, 2020 14:22

Don't change AssemblyVersions in installer, leave as it was

4665892

Fix installer tests

35babe3

safern mentioned this pull request Jan 23, 2020

Builds failing with subset violation #1967

Closed

Merge remote-tracking branch 'dotnet/master' into rm-date

6c19aa8

Move AssemblyVersion for installer test assets to right place

4525288

safern marked this pull request as ready for review January 24, 2020 06:41

safern merged commit 1e09e98 into dotnet:master Jan 24, 2020

dagood deleted the rm-date branch January 24, 2020 18:18

dagood mentioned this pull request Jan 28, 2020

Can we use "dev" prerelease tag for local builds, rather than "dev.12345.1"? #246

Closed

ghost locked as resolved and limited conversation to collaborators Dec 11, 2020

Remove date number from dev build version #1835

Remove date number from dev build version #1835

Conversation

dagood commented Jan 16, 2020 • edited by safern Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dagood commented Jan 16, 2020

safern commented Jan 16, 2020

dagood commented Jan 16, 2020

dagood commented Jan 16, 2020

safern commented Jan 16, 2020

safern commented Jan 16, 2020

safern commented Jan 17, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tmat Jan 20, 2020 • edited Loading

Choose a reason for hiding this comment

tmat Jan 20, 2020 • edited Loading

Choose a reason for hiding this comment

dagood commented Jan 17, 2020

safern commented Jan 17, 2020

safern commented Jan 17, 2020

mmitche commented Jan 17, 2020

dagood commented Jan 17, 2020

tmat commented Jan 20, 2020

dagood commented Jan 20, 2020 • edited Loading

dagood commented Jan 20, 2020

tmat commented Jan 21, 2020 • edited Loading

tmat commented Jan 21, 2020

dagood commented Jan 21, 2020

safern commented Jan 21, 2020

dagood commented Jan 21, 2020

safern commented Jan 22, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dagood commented Jan 23, 2020

safern commented Jan 23, 2020

elinor-fung commented Jan 23, 2020

safern commented Jan 23, 2020

safern commented Jan 24, 2020

dagood commented Jan 24, 2020

dagood commented Jan 16, 2020 •

edited by safern

Loading

tmat Jan 20, 2020 •

edited

Loading

tmat Jan 20, 2020 •

edited

Loading

dagood commented Jan 20, 2020 •

edited

Loading

tmat commented Jan 21, 2020 •

edited

Loading