删除已弃用的 API 的路径

发布于 2024-11-15 15:40:38 字数 250 浏览 1 评论 0原文

我们的代码库中有一些外部 API 多年来已被弃用,但没有明确的路径说明谁/何时删除它们。您建议我们如何删除它们?我们是否可以考虑已弃用的 API,例如超过 2 年或 3 个版本之前就足以删除它们?或者我们应该首先明确传达每个 API 的删除策略,并在几个版本发布后开始删除它们?

有什么见解吗?你是怎么处理这个问题的?

澄清:我们在已弃用的接口上一直都有已弃用的注释,问题是我们从未明确传达过这些注释何时可能不再存在。

We have some external APIs in our codebase that have been deprecated over the years, with no clear path on who/when to remove them. How would you recommend we would go about removing them? Can we consider APIs that have been deprecated for example >2 years or 3 releases back old enough just to remove them? Or should we first clearly communicate a removal strategy for each individual API and start removing them a couple of releases forward?

Any insights? How have you handled this?

Clarification: We have always had deprecated annotations on our deprecated interfaces, the problem is that we have never clearly communicated when those might no longer exist.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

狼亦尘 2024-11-22 15:40:38

当我们弃用某个 API 时,我们会向用户宣布弃用,并将弃用的 API 保留用于以后的两个版本。但为了确保每个人都知道该 API 已被弃用(语言为 C),我们在公开该 API 的标头中添加了 #error This module is deprecated since ...

保持该状态直到您最终决定删除该 API。

When we deprecate an API, we announce the deprecation to our users and keep the deprecated API for two further releases. But to ensure, that everyone knows that the API is deprecated (language is C), we put an #error This module is deprecated since ... in the header that makes the API public.

Keep that state until you finally decide to delete the API.

爱冒险 2024-11-22 15:40:38

我想说这主要取决于谁使用你的 API。如果您无法控制的用户使用您的 API,那么您在更改它时需要更加小心。如果它严格在内部使用,那么这主要是一个质量保证问题——你如何确定没有任何东西仍在调用旧函数?

我在一些(非常小的)项目中采取的一般方法是调整我们的调用者不再使用旧的 API,然后记录不再支持旧的 API 函数(可能只需要源代码注释,具体取决于根据你的情况)。然后,在测试新 API 的完整测试/发布周期之后,我们将完全删除旧函数,然后运行另一个完整的测试/发布周期,以确保我们没有错过旧 API 的任何隐藏调用者。

根据具体的 API,您也许可以在旧函数中放置一些调试代码,以便在有人仍在使用(或错误地开始使用)旧 API 时找到证据。

I would say this depends mostly on who uses your API. If your API is used by users you have no control over, you need to be much more careful about changing it. If it's used strictly internally, then it's mainly a QA concern--how can you be SURE nothing is still calling an old function?

A general approach I've taken in some of my (very small) projects has been to adjust our callers to no longer use the old API, then document that the old API functions are no longer supported (possibly with just a source comment, depending on your situation). Then after a full test/release cycle of testing the new API, we'll delete the old functions entirely, and then run through another complete test/release cycle to make sure we didn't miss any hidden callers to the old API.

Depending on the exact API, you might be able to put some debugging code in the old functions, so that you'll find evidence when someone is still using (or erroneously starts using) the old API.

三人与歌 2024-11-22 15:40:38

在某些编程语言/环境中,您可以将函数装饰为已弃用,或者至少在调用函数时插入编译器警告/消息。这是提醒(窃听?)用户停止使用这些功能的好策略。

In some programming languages/environments you can decorate functions as deprecated or at least insert compiler warnings/messages when they are invoked. This is a good tactic for reminding (bugging?) users to stop using those functions.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文