3

有时，当改进远大于缺点时，您需要引入向后不兼容的更改。可以轻松切换到旧行为，但用户必须注意此类更改。

因此问题是：如何宣布未来对 FLOSS（开源）项目的向后不兼容的更改，以便用户可以为他们做好准备，或者改变他们的使用，或者配置程序使用旧的行为。

因为是OSS项目，被各个发行版独立打包，可以自动升级，无需用户干预。然后向后不兼容的更改可能会弄乱某人的工作流程（例如第三方脚本）。

目前考虑（和使用）的途径：

  • 项目邮件列表
  • 项目主页
  • 发行说明（第一个警告，然后是公告）
  • 维护者的博客

编辑 1：此（向后不兼容）更改将在某些主要版本中发生。

所有更改都是关于添加保护措施（拒绝可能彻底混淆新手用户的命令），或者将默认值更改为更合理的值。

编辑 2：在过渡期间，默认配置（意味着更改为默认拒绝/拒绝）更改为warn，并说明如何关闭警告，这也可以防止默认行为的向后不兼容更改。

但如果它是自动化系统，可能无济于事......

有问题的项目是Git，分布式版本控制系统；
请参阅在gitster 的日志中向用户提供早期警告（Junio C Hamano 博客）

4

5 回答 5

9
  • 更改版本号的专业
  • 通过您可以使用的所有途径宣布它
  • 在自述文件中添加突出的公告
  • 如果需要数据库或其他更改，请添加在新旧之间转换的代码
  • 添加检测使用过时方法、数据存储等的代码，并在执行破坏性更改之前提醒用户
  • 在主要的 Q/A 网站上询问相关的常见问题解答类型的问题，这样当人们有疑问时，使用简单的搜索即可立即获得答案

但主要版本号是主要目标 - 人们预计 1.x 到 2.x 的转换会导致问题，并且在升级时更加小心。

-亚当

于 2009-02-17T14:01:06.283 回答
2

你有很好的答案来宣传这个词。但是迁移我自己的思维方式对我来说是最大的问题，特别是当我的肌肉记忆中已弃用的功能时。不学习比学习更难。

当我实际使用将要更改的命令时，收到有关即将发生不兼容的警告特别有用，尤其是在更改默认值的情况下。就像是： 

 $ git foo  
 Note: git foo currently defaults to HEAD. Starting with
 version 2.0, git foo will instead default to master.
于 2009-02-17T22:09:45.670 回答
1

我可以选择 RSS（如果存在）、Twitter（如果存在）、邮件列表（在更新即将结束时至少发送 3 次）、主页（使其对比鲜明，因此很容易看到）和博客，当然. 发行说明很少被阅读，所以把它作为最后一点信息。

（我将此作为第一个答案发布，但没有出现）

于 2009-02-17T14:17:32.140 回答
1

以上所有加号。

如果您有更改：

非破坏性命令的确切语法将更改为破坏性命令

我看不到任何选择，而是使更改更具破坏性以使旧命令完全无效，因此如果用户升级并尝试（或很可能是脚本尝试）旧样式命令，它会在 stderr 上以描述性错误消息终止。使用 stderr 对具有非破坏性的细微（或不那么细微）更改的命令发出警告消息也是一个好主意。破坏性的定义在源存储库上稍微复杂一些

对简单的弃用方法使用标准错误警告通常很好，但有些人会抱怨它破坏了他们的（写得不好的）脚本。在这些情况下，静默弃用发布（所有非侵入性形式的弃用），然后是口头（stderr 警告）发布，然后可能（见下文）发布无功能但当前的发布，然后是完全删除。最后一个非功能版本将在很大程度上依赖于所讨论的项目，因为它可能比它的价值更多，特别是对于那些表现良好并及时了解已弃用功能的用户。

由于您引用的具体更改是删除内置插件，这应该没问题我可能不会在非功能模式下使用内置插件完成一个版本，但我不太了解该项目，无法确定.

注意代码而不是脚本级别的更改，在许多现代语言中，可能会留下带有属性/注释的方法存根，这将完全隐藏它们对智能感知以及拒绝针对它们进行编译。这使得它们的存在（如果使用了一个简单的例外）比运行时 MissingMethodException 或其他什么更好地发现你不能使用它们。

于 2009-02-17T14:20:45.690 回答
-1

只是我的 0.02 美元。现代开发环境（特别是 .NET）提供了向开发人员报告某些 API 已被声明为过时/弃用并将在未来版本中删除的方法。Microsoft C/C++ 编译器有#pragma deprecated。

如果您的环境不支持这些，请依靠版本控制来提供兼容反馈。

于 2009-02-17T14:02:06.233 回答