假设我的api中有一个名为foo
的方法。在我的api的下一个版本中,我想用bar
替换此方法。我该怎么做?
有两种选择:
1)只需删除foo
即可。在发行说明中,声明此方法已被bar
替换。当他们尝试使用我的新库构建时会破坏客户端,但是谁在乎呢?他们只需要自我修复。
2)弃用了标记foo
,并在发行说明中声明应该首选bar
。调用不推荐使用的方法时记录警告。然后在下一个版本中,完全删除foo
。这为客户提供了一个小警告窗口。
你会做什么?
答案 0 :(得分:5)
绝对做2。
上面的1不仅影响编译时,而且如果你的库jar被最终用户替换,导致运行时错误。
答案 1 :(得分:0)
您的秒数选择是替换方法的标准选择。
答案 2 :(得分:0)
如果客户端程序在我的控制之下,并且我对它们有良好的测试覆盖率,那么我将客户端切换到新签名并删除旧签名。否则我会弃用旧签名。
答案 3 :(得分:0)
做2,然后是1。
在您的“小警告窗口”中,向您的客户明确表示bar
风靡一时,并确保所有(或由您自行决定,最多)不再依赖foo
在从你的图书馆中删除自重之前。通过这种方式,您的客户可以在自己方便的情况下解决问题,而不是被二进制中断强迫。
当然,正如David所说,你需要根据用户群的大小来判断自己的判断。如果这是一个仅由几个密切联系人使用的小型库,那么进行更改可能更有效,但是良好形式标记为已弃用。