这是一个样式问题，并且在公共SDK的上下文中，由于向后兼容性要求，无法删除方法。
我已经在一些地方看到，当添加新版本的方法时，它将具有相同的名称，但有一些数字前缀，例如，
void doTheThing2(...) {...};
乍一看，这非常难看，显然没有做任何事情来传达方法的实际差异。另一方面，我发现它通常更加丑陋，有时甚至无法捕获名称中方法“版本2”的语义变化。例如。，
boolean doTheThingButReturnResultCode(...) {...};
如果你有方法的第3版，那么上帝是否禁止呢？
显然我用Java编码，但这个问题并不是特定于Java。我意识到这里没有客观的答案，但希望能够理性地得到一些意见。
我会说这是气馁的，但并非无效。我认为你非常有正确的想法，在公共API中保持方法在很长一段时间内的兼容性，并明确宣传弃用期。
后缀的一个问题是新方法最终会在1-2个主要API版本之后成为主要的使用方法。然而，这破坏了工作程序员的流程 - 你得到一个仍然附加到方法的遗留后缀。甚至在此之前，method()和method2()之间的含义通常不是一个明确的约定。
由于英语是一种富含同义词的语言，我已经看到它们在方法级别上比版本后缀更受欢迎。这通常不是牺牲清晰度和简单性。例如addItem() (deprecated)可能成为storeItem()。当在API中的多个位置遵循新的命名约定时，这尤其有效。然后addWidget()和addWudget()成为storeWidget()和storeWudget()。
您可以在Java和Python API本身中看到这种同义词方法 - 它们很少使用数字后缀。也许String.subSequence()方法可以被认为是String.substring()的第2版。
数字后缀的另一个问题是它不清楚数字的版本是什么。它是该方法的一个版本吗？ API中的？一年？一个Java版本？ API主要版本可能最有意义，但是如果不添加像addItemJava2()或addItemV2()这样的更长的后缀，很难一致地给出这个上下文。在主要API版本更改后使用孤立的数字后缀也变得不直观。我现在应该使用addItemv3()它是API版本5吗？
我已经看到在接口和类名中使用更有效的数字后缀。也许这是因为它们通常是名词，而不是动词，它们在方法名称中更常见。拥有CarModel2比drive2()更有意义。或者也许是因为它们是接口，一致的上下文更容易强加到API的更广泛的表面，因此API发现的用户也是如此。
由于这涉及风格，其中一些可能是主观的，但这些是一些需要考虑的设计压力。