自由软件发布方法惯例

Eric Steven Raymond

版本号:3.0

$日期:2000年8月21日 18:29:23 $

本文档的修订历史
3.0修订版 2000年8月12日 修订人:esr
第一个DocBook版。SourceForge上的建议和一个主要章节被加入本文档。

本文档详细说明了如何发布一个Linux系统下的自由软件项目。依据这些说明,你就可以让用户非常容易的编译并使用你的代码,同时也可以让其他热心的开发人员很容易读懂你的代码并参与到你的项目中来,并优化、改进她。

本文档对与开发者来说应该算是是一本必读教材。即使是有经验的程序员在发布他们的软件时也需要温习一下本文档。另外本文档会定期修订以反映软件发布实践中更好的做法。


目录

1. 简介
1.1. 本文档的来由
1.2. 如何获得本说明更新的版本

2. 优秀项目—档案—的命名惯例
2.1. 用GNU风格的命名习惯,档案名加主版本号.辅版本号.补丁编号
2.2. 有时候也还要尊重一些在局部范围内流行的惯例
2.3. 尽量找一个独一无二并且又很容易输入的项目名称(前缀)

3. 选择一个好的许可证和版权说明(从理论上探讨)
3.1. 开源与版权
3.2. 怎样才有资格被称为开源软件

4. 选择好的许可证和版权(实践篇)
4.1. 让你自己或者自由软件基金会成为软件的版权所有者
4.2. 采用遵照开源定义的许可证
4.3. 如果没有特别的需要,最好不要自搞一套许可证

5. 好的开发习惯
5.1. 写标准ANSI C程序或者可移植的脚本程序
5.2. 遵守C程序的可移植惯例
5.3. 使用autoconf/automake/autoheader工具
5.4. 发布前要仔细的检查代码
5.5. 发布前要仔细的检查文档和Readmes文件

6. 制作项目发布包的好经验
6.1. 确保tar包解压时会建一个独立的新目录
6.2. 制作一个README文件
6.3. 遵照标准文件命名规则
6.4. 为项目升级做好准备
6.5. 提供RPM包

7. 好的文档编写惯例
7.1. 现行的一些好的做法
7.2. 也许未来会有些更好的做法

8. 好的沟通方式
8.1. 在c.o.l.a和Freshmeat上公布
8.2. 在相关主题新闻组中公布
8.3. 建一个与项目相关的网站
8.4. 维护一个项目相关邮件列表
8.5. 在各大主要项目库站点中发布

9. 好的项目管理经验