软件发布实践 HOWTO

Eric Steven Raymond

修订历史
修订版 4.12013-01-14修订者:esr
从代码仓库检出以确保基于最新代码进行修补。 Freshmeat 更名了。 USENET 主题组不再那么显眼。
修订版 4.02010-04-11修订者:esr
不再需要在项目级别提供 RPM 或 deb 包。打包基础设施在这方面已经做得很好。关于配置和 autotools 的新警告。 AsciiDOC 现在是文档母版的可用替代方案。
修订版 3.92004-11-28修订者:esr
关于良好修补实践的新材料。 推荐使用 Electric Fence 和 valgrind 而不是专有工具。
修订版 3.82003-02-17修订者:esr
站点移动后的 URL 修复。
修订版 3.72002-09-25修订者:esr
指向 DocBook Demystification HOWTO。
修订版 3.62002-09-12修订者:esr
加入了 Keith Bostic 关于可移植性的材料。
修订版 3.62002-08-14修订者:esr
重写了关于文档实践的章节,因为 XML-Docbook 现在已经成熟。
修订版 3.52002-07-04修订者:esr
添加了关于提供校验和的章节。 引用了 doclifter。
修订版 3.42002-01-04修订者:esr
更多关于良好修补实践的内容。
修订版 3.32001-08-16修订者:esr
关于如何发送良好补丁的新章节。
修订版 3.22001-07-11修订者:esr
关于不依赖专有组件的说明。
修订版 3.12001-02-22修订者:esr
LDP 风格指南修复。
修订版 3.02000-08-12修订者:esr
第一个 DocBook 版本。 添加了关于 SourceForge 的建议以及关于文档实践的主要章节。

本 HOWTO 描述了 Linux 和其他开源项目的良好发布实践。 通过遵循这些实践,您将尽可能方便用户构建和使用您的代码,并方便其他开发人员理解您的代码并与您合作改进它。

本文档是新手开发人员的必读之物。 经验丰富的开发人员在即将发布新项目时应回顾它。 它将定期修订,以反映良好实践标准的演变。


目录
1. 引言
1.1. 本文档的目的?
1.2. 本文档的新版本
2. 良好的修补实践
2.1. 发送补丁,不要发送整个归档文件或文件
2.2. 针对代码的当前版本发送补丁。
2.3. 不要包含针对生成文件的补丁。
2.4. 不要发送仅调整版本控制 $-符号的补丁集。
2.5. 使用 -c 或 -u 格式,不要使用默认的 (-e) 格式
2.6. 在补丁中包含文档
2.7. 在补丁中包含解释
2.8. 在代码中包含有用的注释
2.9. 每个补丁只修复一个错误或添加一个新功能。
3. 良好的项目和归档文件命名实践
3.1. 使用 GNU 风格的名称,带有词干和主版本号.次版本号.补丁号。
3.2. 但在适当的地方尊重本地约定
3.3. 努力选择一个唯一且易于键入的名称前缀
4. 良好的许可和版权实践:理论
4.1. 开源和版权
4.2. 什么符合开源资格
5. 良好的许可和版权实践:实践
5.1. 让自己或 FSF 成为版权持有人
5.2. 使用符合开源定义的许可证
5.3. 如果可以避免,请不要编写自己的许可证。
5.4. 使您的许可证在标准位置可见。
6. 良好的开发实践
6.1. 选择您可以使用的最具可移植性的语言
6.2. 不要依赖专有代码
6.3. 构建系统
6.4. 在发布前测试您的代码
6.5. 在发布前对您的代码进行健全性检查
6.6. 在发布前对您的文档和 README 进行健全性检查
6.7. 推荐的 C/C++ 可移植性实践
7. 良好的发行版制作实践
7.1. 确保 tarball 始终解压缩到单个新目录中
7.2. 拥有一个 README 文件
7.3. 尊重并遵循标准文件命名实践
7.4. 为可升级性而设计
7.5. 提供校验和
8. 良好的文档实践
8.1. 文档格式
8.2. 良好实践建议
9. 良好的沟通实践
9.1. 在 Freecode 上公告
9.2. 拥有一个网站
9.3. 托管项目邮件列表
9.4. 发布到主要归档站点
10. 良好的项目管理实践