For discussion. Could we take these constants from this file automatically?

For discussion. Could we take these constants from this file automatically?

I don't know how to parse C source in PowerShell. Manual parsing sounds like a bad idea. Also, U_ICU_VERSION_MAJOR_NUM is defined in libicu-dev header.

For discussion. Could we take these constants from this file automatically?

I don't know how to parse C source in PowerShell. Manual parsing sounds like a bad idea. Also, U_ICU_VERSION_MAJOR_NUM is defined in libicu-dev header.

We should not assume what platform we are building on.

We should not assume what platform we are building on.

@TravisEz13, this is agnostic of build platform? Or can you clarify what you meant?

We should not assume what platform we are building on.

@TravisEz13, this is agnostic of build platform? Or can you clarify what you meant?

We should be agnostic of build platform. So, if we do pull any information in, it needs to be from public .NET information.

We should not assume what platform we are building on.

@TravisEz13 — is this agnostic of the build platform, or could you clarify what you meant?

We should be agnostic of the build platform. If we do pull any information in, it needs to come from public .NET information.

I’m happy with the current state of the PR, where we align with the version range used by the .NET runtime; which I believe you’re also okay with. The $BuildICUVersion can be updated once a year before each release. This implies the package remains compatible with up to 30 future ICU versions supported by the .NET runtime. Given ICU’s roughly biannual release cadence, that translates to about "15 years of compatibility with the latest libicu" for a given PowerShell version.

We should not assume what platform we are building on.

@TravisEz13 — is this agnostic of the build platform, or could you clarify what you meant?

We should be agnostic of the build platform. If we do pull any information in, it needs to come from public .NET information.

I’m happy with the current state of the PR, where we align with the version range used by the .NET runtime; which I believe you’re also okay with. The $BuildICUVersion can be updated once a year before each release. This implies the package remains compatible with up to 30 future ICU versions supported by the .NET runtime. Given ICU’s roughly biannual release cadence, that translates to about "15 years of compatibility with the latest libicu" for a given PowerShell version.

It would be wonderful if .NET exposed this and we could generate the code, but otherwise this seems like a step forward.
Maybe add comments on what the plan is to the script?

LGTM, but packaging has been undergoing some changes. CI is broken. I have a PR to fix it. We need to take that PR first and rerun tests.

#26315

@TravisEz13, if it looks good, can this be merged? Will it be part of the upcoming release?

@kasperk81 we have all the changes to the packaging commited that we expect. I'll run the CI again and verify.

@TravisEz13 i've fixed the typo from suggestion #26304 (comment). can you rerun the CI?

@TravisEz13 good to merge?

Mark as 7.5-consider and 7.4-consider, because .NET changed the supported OS for .NET 8 and .NET 9 to include Debian 13 in the matrix.

https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md#linux
https://github.com/dotnet/core/blob/main/release-notes/9.0/supported-os.md#linux