cuDNN API 演化 （二）—— Deprecation 策略

本博客第一篇介绍了 cuDNN API 的演化规则。这一篇介绍它的 Deprecation 策略。

按照 cuDNN API 的演化规则，随着 cuDNN 版本的更新，同一个 API 会有越来越多带后缀的版本，会使得 cuDNN 臃肿、维护变得困难。因此，还需要 Deprecation 策略。所谓 Deprecation 策略，即演化过程中，对某些带后缀 API 舍弃的机制。

cuDNN 新版本会确保向后兼容两个版本。上篇以 cuDNN 从 v2 演化到 v4 为例，因此不涉及到 Deprecation 策略。在这一篇，进一步演化到 v5, 介绍 Deprecation 策略。

如上篇所述，从 v2 演化到 v4，某个 API cudnnMyName 在 cuDNN v4 有如下三个版本，分别为

• _v2 修饰，即 cudnnMyName_v2, 以支持 v2 版本
• _v3 修饰，即 cudnnMyName_v3, 以支持 v3 版本
• 不带任何修饰，即 cudnnMyName， 功能与带 _v3 修饰的一样

那么演化到 v5 时，它们各自如何变化呢？记住，v5 版本只向后支持两个版本，即支持到 v3 。所以，该 API 三个版本有如下变化

• 舍弃 _v2 修饰的版本
• 由于 _v3 修饰的版本与不带修饰的版本功能相同。因此，舍弃带 _v3 修饰的版本、保留不带修饰的版本

此时，该 API 在 v5 中只有一个版本——不带任何修饰。从 v2 到 v5࿰