| 14 Dec 2024 |
 6pak | https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/partial-byte-reads-in-streams | 02:24:40 |
 GGG | oh | 02:24:52 |
| 6pak | impactful as in I've seen something break myself | 02:24:59 |
| 6pak | it's generally really subtle stuff | 02:25:11 |
| 6pak | almost never actual binary breaking changes | 02:25:35 |
| 6pak | actually even BinarySerializer wasn't fully removed was it? | 02:26:04 |
| 6pak | * actually even BinaryFormatter wasn't fully removed was it? | 02:26:20 |
| GGG | yeah, seems to be the case from what I'm seeing | 02:26:52 |
| 6pak | yeah it just throws | 02:27:00 |
| 6pak | I don't know any case of an api being removed then | 02:27:06 |
| GGG | the actual class hasn't, but it won't let you compile and all of its members throw now | 02:27:15 |
| GGG | * the actual class hasn't, but it won't let you compile new code using it and all of its members throw now | 02:27:22 |
| GGG | I was thinking we could use this roll forward feature to help with .NET EOL, but the EOL includes the packages, so it's a no-go | 02:28:40 |
| 6pak | which packages? | 02:29:16 |
| GGG | all of the runtime ones, System.Text.Json, System.IO, etc. | 02:31:18 |
| 6pak | wym by help with .NET EOL | 02:31:50 |
| GGG | there's currently a huge effort to upgrade every package that uses .NET 6 or 7 to a maintained version | 02:32:21 |
| GGG | if we could just roll them forward then it would avoid possible security issues from them being EOL | 02:32:35 |
| GGG | but then there's the runtime packages as well that wouldn't be rolled forward | 02:32:46 |
| 6pak | corlib would be taken from the latest runtime | 02:33:18 |
| GGG | like all of these: https://github.com/NixOS/nixpkgs/blob/9a5c9fb07412bf180b6c91d12b4bfaa06596f92c/pkgs/development/compilers/dotnet/versions/6.0.nix#L11-L572 | 02:33:21 |
| 6pak | STJ if referenced out of band you should update anyway | 02:33:28 |
| 6pak | because that gets CVEs often | 02:33:34 |
| GGG | yeah | 02:33:37 |
| 6pak | and if you dont update sdk then you wont be able to build anyway | 02:33:46 |
| GGG | but if you reference the SDK one, it'd be stuck on that, wouldn't it? | 02:33:49 |
| 6pak | it should be trivial to bump the sdk anyway | 02:33:53 |
| 6pak | you can update STJ by just referencing a newer version | 02:34:14 |
| GGG | or so you'd think, there are apparently a few packages where upstream hasn't upgraded yet | 02:34:17 |
| GGG | yeah, but that'd become a patch we'd have to maintain | 02:34:25 |
