在 dotnet core 3.0 为了支持 IEEE 浮点数计算标准，修改了 Math.Max 的算法，于是在 WPF 的 Track 里面的布局依赖于之前的计算，于是在 dotnet core 3.0 的修改就让布局计算不对了。改动现有 API 的行为会让现有的代码出现不兼容问题，那么要让一个框架能稳定支持升级需要满足什么条件
在我准备睡的过程，某 神樹 桜乃 告诉我现在的 Math.Max 对于 0 和 NaN 的返回和之前不一样，于是在他的帮助下，我找到了dotnet core 3.0 的新特性，符合 IEEE 标准的浮点计算的提交 在这个提交里面，作者说明了这个提交将会是改变 API 行为的
于是刚好在 WPF 的 Slider 用到了 Track 的布局，刚好在布局里面就依赖了 Math.Max(0,NaN) 返回 的是 NaN 而不是 0 的坑，详细请看 神樹的回复
本来 dotnet core 遵守 IEEE 标准是好的，因为有一个标准可以让多个语言迁移成本降低，但是在 .NET Framework 已经用了这个坑很久了，没有人能说明有多少以前的代码会依赖于这个坑。于是修改 dotnet core 3.0 浮点计算的作者就提议不更改原有的 API 的行为，另外新增新的 API 而不是改变原有的 API 用来兼容现在的代码，请看Expose Math.MaxNumber and Math.MinNumber functions that don’t propagate NaN
我十分同意一个稳定的框架的 API 设计是能做到上下兼容的，一个不兼容的 API 只需要满足以下条件
- 接口更改，包含方法或属性名等的变更
- 返回值更改
- 公开属性更改，包括属性类型和属性可访问
- 公开 API 行为修改
- 方法参数变更，包含参数类型和参数个数
作为一个公开的框架，将会有很多历史问题，一个发布出去的 API 将会被很多小伙伴在很多地方使用，如果变更了不兼容的 API 从版本号规范上，需要升级主版本号。在版本号规则，升级主版本号就是表示存在 API 不兼容，基本上就是需要修改现在的代码才能跑起来。而升级次版本号就是表示有新增的 API 可以不更改原有的代码就可以升级库。也就是只要不是主版本号更改，那么就是愉快升级库而不需要考虑兼容
作为超级多项目引用的基础 dotnet core 库是需要做到上下兼容的，任何很小的 API 不兼容都需要其他很多项目很大的兼容代价
如何设计一个好的框架，请看好的框架需要好的 API 设计 —— API 设计的六个原则 - walterlv
现在 WPF 和 dotnet core 都是开源的，如果遇到任何的问题都可以在社区上询问
本文会经常更新，请阅读原文： https://dotnet-campus.github.io//post/%E4%BB%8E-dotnet-core-3.0-%E7%9A%84%E7%89%B9%E6%80%A7%E8%AE%A9-WPF-%E5%B8%83%E5%B1%80%E5%A4%B1%E6%95%88%E8%AE%A8%E8%AE%BA-API-%E5%85%BC%E5%AE%B9.html ，以避免陈旧错误知识的误导，同时有更好的阅读体验。
本作品采用
知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议
进行许可。欢迎转载、使用、重新发布，但务必保留文章署名
lindexi
（包含链接：
https://dotnet-campus.github.io/
），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请
与我联系
。