删除不赞成使用的方法要等待多长时间？[关闭]

38

我正在维护公共API，并且必须弃用一种方法。

是否有关于删除我应该弃用一种方法之前多少个月/年/版本的一般规则？

java deprecation

— 戴维·戴夫
source

27

一般规则是“只要您和/或您的客户需要它，就一直保存它”。

— 罗伯特·哈维

15

定义“公共”。免费的开源软件，带有通常的“自担风险”免责声明？或存在合同的出售软件？

— 布朗

11

这在很大程度上取决于您的用户所处的市场以及他们是否向您支付API费用。

— 18年

10

这还取决于您为什么要“贬值”折旧。旧方法有安全隐患吗？您是否刚刚找到了由于不幸的设计决定而使旧方法从根本上无法固定地不稳定的原因？现在的旧方法是否比过去慢得多？您的目标系统（例如嵌入式系统）上的内存是否用完了，而您实际上无法同时使用这两个API？还是您只是找到一种“更好”的方式，而只想清除旧代码以减少维护开销？

— jrh

8

java.io.StringBufferInputStream自JDK 1.1（1997？）开始不推荐使用。这个问题没有正确或错误的答案。这取决于您是否需要提供向后兼容性。

— Laiv

52

至少，在删除不推荐使用的方法之前，应将其保留在一个版本中，当我将其写出来时，这似乎很明显。我认为没有最长的时间，但是如果您从未真正删除它们，则弃用将变得毫无意义。

主版本发布是删除不推荐使用的方法的好时机。次要发行版通常不应包含重大更改。正如cHao在评论中指出的那样，弃用并不一定意味着最终会被删除，因此，如果您打算在弃用之后删除内容，则应明确指出并在时间表上提供一些指导。

— 吉米·詹姆斯（JimmyJames）
source

58

弃用不一定与最终删除有关，因此不删除而不弃用并不是没有意义的（如果向后兼容性很重要，通常是正确的选择）。通常，重点只不过是“我们现在有更好的方法，所以您不应该再这样了”。

— cHao

9

@cHao如果不赞成使用某些内容，则不应期望它继续存在。我想如果您想在项目中做出特别声明，说明您不会删除不推荐使用的功能，那很好，但是否则，是的，这暗示着最终将被删除。我要说的是，如果您对此不保持某种严格的态度，人们可能会相信它永远不会发生。这是Java的最新版本提出的，该版本已弃用了十年或更长时间的功能现在已被删除。

— JimmyJames

6

@cHao我宁愿一个项目删除其过时的功能。实际激励用户切换的好处不仅在于，而且还可以防止已弃用的界面干扰其他改进。

— jpmc26

9

@cHao这是上下文相关的事情。以我的经验，弃用政策是明确的。明确指出，过时的功能将在将来的某个时候删除。通常不推荐使用的功能会出现问题，使它难以使用，这不仅取决于您是否重视向后兼容性。

— JimmyJames

6

我要同意@JimmyJames的意见，即弃用显然意味着即将被移除。弃用期作为提供临时向后兼容性的一种方式存在，因此使用者可以迁移到较新的功能。绝对不应期望已弃用的功能将无限期保留。如果将保留旧功能，则没有理由不推荐使用。

— 埃里克·金

17

这完全取决于您为用户提供的稳定性保证，以及您希望给用户带来多少痛苦。

理想情况下，您的API使用semver，以便任何重大更改都会导致主版本号增加。实际上，希望几乎永远不要这样做。如果您的API是通过某个程序包管理器安装的，则可能需要在重大更改后创建一个新的程序包名称，以便简单的升级不会引起冲突（例如myapi2 v2.123.4vs myapi3 v3.2.1）。如果您的程序包管理器支持更严格的版本依赖关系（例如，这样的依赖关系规范~v2.120不包含v3.*），那么这可能是不必要的，但是不同的程序包名称具有可以很容易地并排使用不兼容版本的优点。即使在使用semver时，明智的做法是有一个弃用期。

Semver并非总是适用。然后，传达明确的稳定性策略就变得更加重要。例如：

实验功能可能会删除，恕不另行通知。
出于安全原因，可以随时删除功能。
其他功能将仅被删除
- ……在已发布的版本中被弃用之后
- …该版本至少存在三个月
- …并会在主要版本中有一个标记。

当您有常规版本时，这样的策略特别有效，因此有一个明确的弃用期，例如一年。

除了将API的任何部分标记为已弃用之外，您还应该广泛宣传弃用。例如：

在您的变更日志中有关于未来方向和弃用的部分。
在执行弃用之前，广播您要弃用的意图，并听取社区的意见，以查看是否存在重大异议。
传达这些变化将带来什么好处。根据您的用户群，新闻通讯，演示文稿，博客文章或新闻稿可能是合适的媒体。试一下“我们正在创建一个很棒的新功能！（这需要删除广泛使用的旧功能）”比没有上下文删除功能要少一些麻烦。

至于选择的确切弃用期限，请首先查看您是否必须履行与用户的任何支持合同。此类合同可能需要您在一段时间内保持兼容性。如果没有，请考虑任何下游影响。尝试不像下游用户那样快地进行更改，以便他们可以经历自己的弃用周期。下游用户将需要一些时间来适应您的更改，因此您的弃用期绝对不应短于一个月。

— 阿蒙
source

3

由于以下原因而

Ideally, your API uses semver so that any breaking change causes the major version number to be incremented. In practice, it is desirable to do this almost never.

被否决：如果您遵循semver表示永远不要引入新的主要版本的方法，那么使用semver来指示重大更改有什么意义？

— mrsmn

6

如果发生重大变化，重命名软件包真的是个好主意吗？那就是版本号的用途。我讨厌当他们也重命名它们时，确实搞砸了Maven依赖管理。

— AJPerez

@AJPerez我理解这不是理想的，但是它可以防止带有传递依赖项的大型依赖关系图中的冲突：我依赖于libfoo，后者依赖于libconflict v1.2.3，并且我依赖于libbar，依赖于libconflict v2.3.4。然后，我无法选择满足所有依赖关系的任何libconflict版本-除非libconflict和libconflict2是不同的程序包。特别是对于Java，这样的重命名很烦人，我必须更改所有导入。幸运的是，Java 9（模块）支持使用相互冲突的版本。

— 阿蒙

1

@mrsmn进行重大更改很烦人，但是您可以打包或命名它们。Semver仅解决了这一问题的一小部分：能够判断升级是否会破坏任何东西。但是，一旦您进行了重大更改，您仍然必须付出更多的努力来适应这种更改。因此，最好让API尽可能地使其稳定。理想情况下，它们的设计方式应使得它们可以扩展而不会破坏向后兼容性。

— 阿蒙

@AJPerez是的。是的，这很好。人们一直在搞乱版本控制。错误修复程序（假定为xxx ++）经常被破坏（假定为x ++。xx）。正如amon所指出的那样（您确实是依赖项的用户），您必须解决一个问题。我知道我的代码可以使用foo 3.2.1，也可以使用foo 3.3.0。我知道我的代码适用于foo，它可能适用于foo-2。我之所以使用semver是因为受欢迎，它本身并没有伤害，但是对我来说，真的不知道它能给您带来如此多的收益。

— 贾里德·史密斯

14

理想情况下，您将要等到没有人使用不推荐使用的方法为止。考虑到您使用的是公共API，这很容易跟踪，但最终可能要等待很长时间。

在2015年，Google在其Android操作系统上的stlport API遇到了类似的问题。他们已弃用它并希望将其删除，但仍有大量应用程序在使用它。他们找到了一个聪明的解决方案：

本质上，他们在任何仍使用API并向开发人员提供适当日志消息的应用程序启动期间添加了8秒sleep（）。一个月后，他们将其倍增至16秒。然后又过了一个月，他们可以安全地删除API接口，因为没有人使用它。

这可能是一种非常有效的方法。唯一真正的问题是，如果您的API很旧并且已经使用了不再被积极支持的使用者。不幸的是，您可能无法自己修复此类使用方，但是到那时，除了删除方法并破坏使用方之外，您实际上无能为力。

— 恩扎尔
source

5

可爱。非常可爱。

— 大卫·哈门

8

提供不推荐使用的方法的最短时间取决于使用API的程序的开发周期。作为一个粗略的数字，一年应该足够。

至于必须删除不推荐使用的方法之前的最长时间，我认为没有这种事情。不管您等待多长时间，删除不推荐使用的方法总是会破坏某些东西。某些使用您已弃用的API的程序未得到积极维护，而中断兼容性将意味着此类程序的寿命终止。

我建议您从删除中获得收益时删除不推荐使用的方法：

检测到一个错误，该错误专门影响不推荐使用的方法
您将要重构代码，维护不赞成使用的方法将需要大量的精力
您正在优化库的内部结构，而已弃用的方法不再适用。

仅仅因为不赞成使用X个月/年或因为您要发布新版本而删除不赞成使用的方法，就无缘无故地任意损害了兼容性。

— 德米特里·格里戈里耶夫（Dmitry Grigoryev）
source

7

首先，您应该考虑要弃用还是过时。

不赞成使用的方法应以某种方式有害：安全性，性能，不正确的结果。您想相对快速地摆脱它们，主要版本不超过2个，并在第3个消失。对于足够大的问题，可以在下一个次要版本中删除不推荐使用的版本。

过时的原因是由于某些原因而使有用性降低，例如返回的信息较少或无法正常工作，不包含太多选项，等等。这些可以无限期地徘徊，但是在下一个主要版本中至少应该存在。

— 莫雷诺
source

我想说给出错误结果或损害安全性的方法应立即禁用或修复。性能不佳的方法可以无限期地徘徊，只要它的性能对于某些用户而言是可以接受的。

— 德米特里·格里戈里耶夫

@DmitryGrigoryev：一个次要版本非常接近立即。

— jmoreno

4

答案取决于您为客户提供的服务类型。

在极端情况的一端，从Win 3.1时代开始的Windows.h中出现了错误，这种错误传播了二十年，因为微软坚信向后兼容。

另一方面，许多网络应用程序甚至没有提供过时警告就删除了功能。

客户为您的软件支付多少费用以及他们的工作范围通常很重要。与银行家或联邦航空局相比，研究科学家通常更愿意接受折旧作为进展的一部分。

我在一家公司内部开发软件工作。这些年来，我支持许多团体。一组有“从不删除任何功能”的心态。他们需要能够在5到10年前返回文件，并且对时间尺度进行分析的速度过快，以至于无法使开发人员重新使用功能。一个小组的态度是“确保所有弃用的内容都在补丁说明中，因此我们以后可以找到他们。” 在中间，我们有一个小组，其规则是“必须删除至少1个版本的功能，如果在删除它们之前就使用了打印警告，则必须打印出来。” 该小组的测试套件涵盖了他们所需的功能。每当我们发布新版本时，他们都会针对该版本快速运行测试套件，以查看是否有任何弃用给他们带来麻烦。

— 科尔特·阿蒙
source

4

我正在维护公共API，并且必须弃用一种方法。

为什么需要这样做？是因为有一种新的闪亮的处理方式，所以现在不鼓励使用旧的方法，但是仍然可以正常工作吗？还是因为事情发生了根本变化，实际上是否需要使用旧方法？

如果旧方法没有引起任何实际问题，并且可以坚持下去，那么也可以。如果没坏，就不要修理。您真的需要删除它吗？也许将其标记为已过时，并在文档中包含一条注释，即另一种方法可能更有效，或其他任何方法，但是将其保留在原处可能很好。
如果确实确实需要采用旧方法，或者由于旧方法引起了维护麻烦，或者由于其他更改使它不再具有任何意义，那么请监视其用法，并明确告知弃用情况。给他们一个明确的日期，之后将删除该方法。（理想情况下，在此日期之前不要立即删除它：请等到没有人使用它之后再实际删除它。如果它确实引起问题，则可能需要尽快删除它，但至少要等到使用率下降一次）。小。）
如果旧方法引起安全问题，则您可能需要采取比以前更快的速度，甚至可能在没有警告的情况下将其删除，但是您应该将此更改记录在非常明显的位置，并将敏感消息返回给尝试使用旧方法的客户端。

（其他答案很好地涵盖了后两个要点，但我认为第一个是新的。）

— TRiG
source

1

对于一个公共项目，仅删除它当且仅当您需要。

当您执行不必要的API删除操作时，您将为公司和承包商花费金钱，以至于由于成本高昂的客户流失甚至无法计算。

希望公司和独立程序员停止使用您的项目吗？在您不是很重要时，将它们的东西弄碎足够的时间，您将很快就在那条船上。

deprecation != eventual_removal。如果某个API很危险，则将其删除。如果只是旧的，请将其保留并记录下其更换。

— kayleeFrye_onDeck
source