软件发行惯例HOWTO

Eric S. Raymond <esr@thyrsus.com>

1. 介绍

• 1.1 本文档为什么存在?
• 1.2 本文档的新版本

2. 好的工程命名惯例和存档(archive)命名惯例

• 2.1 把GNU风格的名字用于词干（stem）和major.minor.patch编码。
• 2.2 但在适当的时候尊重原有的习惯（local conventions）
• 2.3 尽力去选择一个独一无二并且易于输入的名称前缀

3. 好的许可证和版权惯例：理论

• 3.1 开放源代码和版权
• 3.2 开放源代码应该施加什么限制（qualifies）

4. 好的许可证和版权惯例：实践

• 4.1 使你自己或者自由软件基金会（FSF）成为版权的所有者
• 4.2 使用符合开放源代码定义的许可证
• 4.3 只要可能避免，就不要编写你自己的许可证。

5. 好的开发惯例

• 5.1 用纯标准C（ANSI C）或者可移植的脚本语言编码
• 5.2 服从好的C可移植惯例
• 5.3 使用autoconf/automake/autoheader
• 5.4 在发布你的代码之前进行完整性检查（Sanity-check）

6. 好的发布创建惯例

• 6.1 确保tar包总是打开到一个单独的新目录中
• 6.2 含有一个README
• 6.3 尊重并服从标准的文件命名惯例
• 6.4 提供RPMs

7. 好的交流惯例

• 7.1 在c.o.l.a中进行通告
• 7.2 在相关主题的新闻组中进行通告
• 7.3 拥有一个网站
• 7.4 为工程提供邮件列表
• 7.5 发布到主存档中

8. 好的工程管理惯例