@stephentoub, @janvorli, should I create a subdirectory 1.0.5 under AnyOS/brotli and move the sources there, so we can tell which version is being used? Currently there is no explicit way to tell which versions of these third party libs we are using (maybe it was even some random / point in time master SHA1 hash).

I think same case is with zlib (https://github.com/madler/zlib/releases) in corefx and libunwind (https://github.com/libunwind/libunwind/releases) in coreclr. If it requires additional patches by us or cherry-pick from their master, we can add those on top of released version, or add patch in source tree like https://github.com/dotnet/source-build maintains them.

test Packaging All Configurations x64 Debug Build

https://ci3.dot.net/job/dotnet_corefx/job/master/job/windows-TGroup_all+CGroup_Debug+AGroup_x64+TestOuter_false_prtest/13679/console failed:

Archiving logs in netci-archived-logs/**
[Pipeline] archiveArtifacts
Archiving artifacts
WARN: No artifacts found that match the file pattern "netci-archived-logs/**". Configuration error?
WARN: ‘netci-archived-logs/**’ doesn’t match anything, but ‘**’ does. Perhaps that’s what you mean?
[Pipeline] isUnix
[Pipeline] bat
[windows-TGrou---0d2c9ac4] Running batch script

D:\j\workspace\windows-TGrou---0d2c9ac4>taskkill /F /IM VBCSCompiler.exe 
ERROR: The process "VBCSCompiler.exe" not found.
[Pipeline] cleanWs

cc: @JeremyKuhne, @ianhays, @joshfree

should I create a subdirectory 1.0.5 under AnyOS/brotli and move the sources there

I think it would be enough to mention the version in the commit text. I did the same thing for libunwind in both coreclr and corert. You can always look at the git history to find that.

Retrieving the version from commit history is bit indirect / complex as it is dependent on source control. If we download the source zip (e.g. https://github.com/dotnet/corefx/archive/release/2.1.zip), this is probably the only version we will not find out in sources. Extra nesting can be avoided by just renaming brotli to brotli-1.0.5, if that's a concern.
However, that's probably not a big deal, just a suggestion.

More than the added indirection, the changing name is what I don't really like. It means that every time we update the library version, we would need to modify the build files to reflect that.
If the commit message doesn't sound like a usable solution, then I'd suggest adding a text file to the same folder as the brotli directory with info on where it came from. Say brotli-version.txt or something like that.

@janvorli, I have added brotli-version.txt with additional release notes URL on second line. Let me know if that is not needed.

@dotnet-bot test Windows x64 Debug Build please