Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[release/6.0] Fix XXHash for stripe size #61923

Merged
merged 3 commits into from
Jan 6, 2022

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Nov 22, 2021

Backport of #61881 to release/6.0

/cc @bartonjs @Tornhoof

Customer Impact

Customers who use the new XxHash32 or XxHash64 types and pass a multiple of 16 (or 32 for XxHash64) to the static hash methods will get a different answer than if they used the instance methods. The answer from the static methods doesn't interoperate with other implementations of XxHash32/XxHash64.

Testing

New unit tests that pass in data that is an even multiple of the stripe size.

Risk

Low, it's a simple fix on a new type (6.0) and adds a regression-prevention test. Delaying the change increases the risk as we will have more compatibility concerns.

@ghost
Copy link

ghost commented Nov 22, 2021

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

Backport of #61881 to release/6.0

/cc @bartonjs @Tornhoof

Customer Impact

Testing

Risk

Author: github-actions[bot]
Assignees: -
Labels:

area-System.IO

Milestone: -

@bartonjs bartonjs added the Servicing-consider Issue for next servicing release review label Nov 22, 2021
@bartonjs
Copy link
Member

@ericstj I feel like I heard that release/6.0 has some automatic detection for OOB servicing. Am I recalling correctly, or do we need to do something explicit still?

@ericstj
Copy link
Member

ericstj commented Nov 22, 2021

Here's a document: https://github.com/dotnet/runtime/blob/4684a1dbab50ea759eaf970302fc9c1f7007bbc2/docs/project/library-servicing.md

TL;DR

To System.IO.Hashing.csproj add

  <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
  <ServicingVersion>1</ServicingVersion>

cc @safern

@bartonjs
Copy link
Member

OK, so "more distributed" but not quite "no brainer". Danke for the pointer.

@@ -4,6 +4,8 @@
<Nullable>enable</Nullable>
<TargetFrameworks>$(NetCoreAppCurrent);netstandard2.0;net461</TargetFrameworks>
<IsPackable>true</IsPackable>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<ServicingVersion>1</ServicingVersion>
<!-- TODO: Remove when the package ships with .NET 6. -->
<DisablePackageBaselineValidation>true</DisablePackageBaselineValidation>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can remove this while you are here (and in main). That will enable compat checking with the 6.0.0 package.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like something still wants it to check compat with 5.0.0:

src/libraries/System.IO.Hashing/src/System.IO.Hashing.csproj : error NU1102: Unable to find package System.IO.Hashing with version (= 5.0.0)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order for it to look for the 6.0.0 package on the main branch you'd need this change: #61437

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@safern -- I think that means we should add #61437 to the servicing branch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jinx 😁 Maybe the way to handle this is to instead remove this property from System.IO.Hashing in #61437 and then bring that whole change to servicing?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Main was refactored so we would have to do something a little different on servicing, but yeah, I can do something on release/6.0 so that it runs package validation against the 6.0.0 version of the package:

<PackageValidationBaselineVersion Condition="'$(PackageValidationBaselineVersion)' == ''">$([MSBuild]::Subtract($(MajorVersion), 1)).0.0</PackageValidationBaselineVersion>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I included the change directly on this PR

@safern safern added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Nov 22, 2021
@safern
Copy link
Member

safern commented Nov 22, 2021

Added no merge as the branch is currently closed.

@Pilchie Pilchie added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Dec 2, 2021
@Pilchie Pilchie added this to the 6.0.2 milestone Dec 2, 2021
@safern safern removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Dec 15, 2021
@danmoseley danmoseley closed this Dec 31, 2021
@danmoseley danmoseley reopened this Dec 31, 2021
@danmoseley
Copy link
Member

@ericstj is this good to merge?

@ericstj
Copy link
Member

ericstj commented Jan 6, 2022

Yes this should be good to merge now.

@ericstj ericstj merged commit 1c2501d into release/6.0 Jan 6, 2022
@safern safern deleted the backport/pr-61881-to-release/6.0 branch January 7, 2022 18:33
@ghost ghost locked as resolved and limited conversation to collaborators Feb 6, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.IO.Hashing Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants