自由软件发布方法惯例
1.优秀项目─档案─的命名惯例
用GNU风格的命名习惯，档案名加主版本号.辅版本号.补丁编号
让档案名称符合GNU命名规则是一个礼人利己的事情，GNU的命名规则是：以所有字母都小写的主名称作为前缀，后跟一个破折号，再跟一个版本号，扩展说明，以及其他后缀。
我们举例说明如下：假定您有一个项目叫做“foobar”，现在她的进展状况是第一版、第二次发布、第三补丁。如果她只有一个档案包（可能就是所有的源码）， 那么她的名称应该是：
foobar-1.2.3.tar.gz
源代码档案包
foobar.lsm
LSM文件（如果您需要将这个项目提交到Metalab上，则需要这个LSM文件）。
请千万不要把名字起成下面的样子：
foobar123.tar.gz
（这会让人误解为是一个名为“foobar123”的项目）
foobar1.2.3.tar.gz
（这会让人误解为是一个名为“foobar1”项目的第2.3版）
foobar-v1.2.3.tar.gz
（许多处理程序将会把她理解为名为“foobar-v1”的项目）
foo_bar-1.2.3.tar.gz
（下划线读起来即不上口，也不容易让别人输入和记住）
FooBar-1.2.3.tar.gz
除非您乐意被看成是市井小人，否则就不要这么写。因为这种写法同样不易读、输入和记忆。
如果您想对源代码包和二进制包有所区别，或者想区分不同类型的二进制包、由不同编译选项编译出来的二进制包，请在文件名的“扩展说明”部分来表示那些信息，扩展说明紧跟在版本号之后。也就是说您可以这样起名字：
foobar-1.2.3.src.tar.gz
（表示源代码包）
foobar-1.2.3.bin.tar.gz
（表示二进制包，但不确定具体类型）
foobar-1.2.3.bin.ELF.tar.gz
（表示ELF格式的二进制包）
foobar-1.2.3.bin.ELF.static.tar.gz
（表示静态链接库的ELF格式二进制包）
foobar-1.2.3.bin.SPARC.tar.gz
（表示SPACE格式的二进制包）
千万不要使用“foobar-ELF-1.2.3.tar.gz”这种格式的名称，因为处理程序对“-ELF” 这样的中缀将难以解释。
一个好的名称将按顺序包含以下几项：
项目名称前缀
破折号
版本号
点
“src”或“bin”标记（可选）
点或者破折号（建议使用点）
二进制格式和选项（可选）
归档和压缩后缀
当两个不同的项目使用同样的主名称时就会产生混淆。他们是Metalab索引文件(http://www.ibiblio.org/pub/Linux)和Freshmeat附录(http://www.freshmeat.net/)。另外还有一个好地方是：SourceForge (http://www.sourceforge.net/)，在这些地方您可以做一点名称检查的工作。
2.选择一个好的许可证和版权说明︰理论篇
开源与版权
任何非公共的东西几乎都有版权，有的甚至还有不止一个版权。
开源软件领域，则是另一番景象﹔在这里版权是用来保护许可证的。版权所有者唯一的权利就是确保许可证的落实。
采用遵照开源定义的许可证
开源软件的定义（OSD）是许可证的公共标准。OSD本身并不是一个许可证﹔而是给出了某个许可证要想成为开源许可证所必须包含的一个最小集合。 OSD和其他辅助资源可以从开源原动力站点获得。
如果没有特别的需要，最好不要自搞一套许可证
4.好的开发习惯
使用autoconf/automake/autoheader工具
如果用C写程序，记住一定要用autoconf/automake/autoheader工具来处理各种移植性的问题，用这些工具完成系统配置信息的收集，创建makefile文件。现在许多人在打算编译源码时只希望通过“configure; make”这样简单的命令就可以得到干净利落的编译，事实上大家就是这么干的。
发布前要仔细地检查代码
发布前要仔细地检查文档和README等文件
文档发布前最好用拼写检查工具查一遍。
5.制作项目发布包的好经验
确保tar包解压时会创建一个独立的新目录
整个项目的简介
项目的WWW站点所在的URL（如果有的话）
指出开发者编译整个项目所在的系统环境，并指出项目可能潜在的移植性问题
重要文件和子目录的结构信息
编译/安装步骤说明，或者指明这些信息所在的文件名（通常是INSTALL文件）
项目主持人和参与者的名单列表，或者指出这些信息所在的文件（通常是CREDITS文件）
最近关于本项目的一些进展情况和新闻，或者指出包含此信息的文件（通常是NEWS文件）
遵照标准文件命名规则
“勇猛的探索者”要想阅读README文件，他们就必须首先浏览解压后项目档案所在的根目录下的文件名。这些文件名本身就在向读者传达着许多信息。如果您遵照标准的命名规则就可以给那些探索者有价值得线索以便他们更好的理解您的意图。
这里列出了一些标准文件名称和他们的涵义。当然并不是所有项目发布时都必须包含所有这些文件。
README或READ.ME
整个项目的结构信息说明，第一个需要阅读的文件。
INSTALL
配置、编译和安装该项目的说明信息
CREDITS
本项目所有贡献者的列表
NEWS
本项目最近的一些新闻和进展状况
HISTORY
本项目的历史发展演变记录
COPYING
指出本项目采用的许可证条款（通常采用GNU GPL）
LICENSE
本项目的许可证条款文件
MANIFEST
本项目的所有文件列表
FAQ
关于本项目的纯文本格式的常见问题解答
TAGS
为Emacs或vi准备的tag标记文件
我们可以看出来，全部大写的文件名一般表示该文件是给人阅读的文档，而不是项目的一个组成部分。
编撰一个FAQ文件可以帮您很多忙。如果某个问题经常被其他人问起，就把这个问题列入FAQ文件﹔然后指导用户在向您发文或提交出错报告前首先阅读FAQ文件。一份好的FAQ文件可以给项目维护者减轻好几个数量级的负担。
另外在每次发布时都保留一个HISTORY文件和NEWS文件，并列明时间信息的做法是非常有好处的。在所有其他文件中，这两个文件可以让您在遇到一些专利侵权法律问题时有所准备（虽然这种情况至今还没有发生过，不过最好还是有备无患）。
为项目升级做好准备
只要您打算为您的项目发布新版本，项目就必定处在不断的变化之中。有些变化是不能向前兼容的。因此您必须认真思考安装程序设计上的问题，就是说让同一项目的不同版本的代码安装后可以共存在一个系统中。这个问题对库项目的发布尤为重要，因为您不能指望所有基于这个库的应用程序都会紧跟您的API接口规范的后尘。
6.好的文档编写惯例
7.好的沟通方式
建一个与项目相关的网站
如果您想围绕项目建立一个用户、开发者的网上社区的话，最好应该建一个网站。一个标准的项目网站一般包括如下内容：
项目的特点（为何要有这个项目，谁会对此项目感兴趣）。
下载项目源代码的地方。
指明如何加入项目相关的邮件列表。
一个常见问题解答列表。
HTML格式的项目文档。
与项目相关或竞争的其他项目或网站的链接。
有的项目站点甚至还有指向源码结构树的匿名访问链接（便于跟踪项目进展）。
8.好的项目管理经验
关于基本开发模式的讨论和对“早发布常发布”的集市开发模式的论述请参考《大教堂和集市》一文。
关于心理动机、社群习俗和化解各种冲突的讨论请参阅《开拓智域》一文。
关于开源软件经济学基础和各种商业运作模式的讨论请阅读 《魔法大锅炉》一文。
需要指出的是这些文章并非自由软件开发的终极论断，不过他们都是经过深思熟虑后的思想结晶，还没有其他文章超越了他们的深度（文章的作者非常希望未来某一天有人超越他们）。
1.优秀项目─档案─的命名惯例
用GNU风格的命名习惯，档案名加主版本号.辅版本号.补丁编号
让档案名称符合GNU命名规则是一个礼人利己的事情，GNU的命名规则是：以所有字母都小写的主名称作为前缀，后跟一个破折号，再跟一个版本号，扩展说明，以及其他后缀。
我们举例说明如下：假定您有一个项目叫做“foobar”，现在她的进展状况是第一版、第二次发布、第三补丁。如果她只有一个档案包（可能就是所有的源码）， 那么她的名称应该是：
foobar-1.2.3.tar.gz
源代码档案包
foobar.lsm
LSM文件（如果您需要将这个项目提交到Metalab上，则需要这个LSM文件）。
请千万不要把名字起成下面的样子：
foobar123.tar.gz
（这会让人误解为是一个名为“foobar123”的项目）
foobar1.2.3.tar.gz
（这会让人误解为是一个名为“foobar1”项目的第2.3版）
foobar-v1.2.3.tar.gz
（许多处理程序将会把她理解为名为“foobar-v1”的项目）
foo_bar-1.2.3.tar.gz
（下划线读起来即不上口，也不容易让别人输入和记住）
FooBar-1.2.3.tar.gz
除非您乐意被看成是市井小人，否则就不要这么写。因为这种写法同样不易读、输入和记忆。
如果您想对源代码包和二进制包有所区别，或者想区分不同类型的二进制包、由不同编译选项编译出来的二进制包，请在文件名的“扩展说明”部分来表示那些信息，扩展说明紧跟在版本号之后。也就是说您可以这样起名字：
foobar-1.2.3.src.tar.gz
（表示源代码包）
foobar-1.2.3.bin.tar.gz
（表示二进制包，但不确定具体类型）
foobar-1.2.3.bin.ELF.tar.gz
（表示ELF格式的二进制包）
foobar-1.2.3.bin.ELF.static.tar.gz
（表示静态链接库的ELF格式二进制包）
foobar-1.2.3.bin.SPARC.tar.gz
（表示SPACE格式的二进制包）
千万不要使用“foobar-ELF-1.2.3.tar.gz”这种格式的名称，因为处理程序对“-ELF” 这样的中缀将难以解释。
一个好的名称将按顺序包含以下几项：
项目名称前缀
破折号
版本号
点
“src”或“bin”标记（可选）
点或者破折号（建议使用点）
二进制格式和选项（可选）
归档和压缩后缀
当两个不同的项目使用同样的主名称时就会产生混淆。他们是Metalab索引文件(http://www.ibiblio.org/pub/Linux)和Freshmeat附录(http://www.freshmeat.net/)。另外还有一个好地方是：SourceForge (http://www.sourceforge.net/)，在这些地方您可以做一点名称检查的工作。
2.选择一个好的许可证和版权说明︰理论篇
开源与版权
任何非公共的东西几乎都有版权，有的甚至还有不止一个版权。
开源软件领域，则是另一番景象﹔在这里版权是用来保护许可证的。版权所有者唯一的权利就是确保许可证的落实。
采用遵照开源定义的许可证
开源软件的定义（OSD）是许可证的公共标准。OSD本身并不是一个许可证﹔而是给出了某个许可证要想成为开源许可证所必须包含的一个最小集合。 OSD和其他辅助资源可以从开源原动力站点获得。
如果没有特别的需要，最好不要自搞一套许可证
4.好的开发习惯
使用autoconf/automake/autoheader工具
如果用C写程序，记住一定要用autoconf/automake/autoheader工具来处理各种移植性的问题，用这些工具完成系统配置信息的收集，创建makefile文件。现在许多人在打算编译源码时只希望通过“configure; make”这样简单的命令就可以得到干净利落的编译，事实上大家就是这么干的。
发布前要仔细地检查代码
发布前要仔细地检查文档和README等文件
文档发布前最好用拼写检查工具查一遍。
5.制作项目发布包的好经验
确保tar包解压时会创建一个独立的新目录
整个项目的简介
项目的WWW站点所在的URL（如果有的话）
指出开发者编译整个项目所在的系统环境，并指出项目可能潜在的移植性问题
重要文件和子目录的结构信息
编译/安装步骤说明，或者指明这些信息所在的文件名（通常是INSTALL文件）
项目主持人和参与者的名单列表，或者指出这些信息所在的文件（通常是CREDITS文件）
最近关于本项目的一些进展情况和新闻，或者指出包含此信息的文件（通常是NEWS文件）
遵照标准文件命名规则
“勇猛的探索者”要想阅读README文件，他们就必须首先浏览解压后项目档案所在的根目录下的文件名。这些文件名本身就在向读者传达着许多信息。如果您遵照标准的命名规则就可以给那些探索者有价值得线索以便他们更好的理解您的意图。
这里列出了一些标准文件名称和他们的涵义。当然并不是所有项目发布时都必须包含所有这些文件。
README或READ.ME
整个项目的结构信息说明，第一个需要阅读的文件。
INSTALL
配置、编译和安装该项目的说明信息
CREDITS
本项目所有贡献者的列表
NEWS
本项目最近的一些新闻和进展状况
HISTORY
本项目的历史发展演变记录
COPYING
指出本项目采用的许可证条款（通常采用GNU GPL）
LICENSE
本项目的许可证条款文件
MANIFEST
本项目的所有文件列表
FAQ
关于本项目的纯文本格式的常见问题解答
TAGS
为Emacs或vi准备的tag标记文件
我们可以看出来，全部大写的文件名一般表示该文件是给人阅读的文档，而不是项目的一个组成部分。
编撰一个FAQ文件可以帮您很多忙。如果某个问题经常被其他人问起，就把这个问题列入FAQ文件﹔然后指导用户在向您发文或提交出错报告前首先阅读FAQ文件。一份好的FAQ文件可以给项目维护者减轻好几个数量级的负担。
另外在每次发布时都保留一个HISTORY文件和NEWS文件，并列明时间信息的做法是非常有好处的。在所有其他文件中，这两个文件可以让您在遇到一些专利侵权法律问题时有所准备（虽然这种情况至今还没有发生过，不过最好还是有备无患）。
为项目升级做好准备
只要您打算为您的项目发布新版本，项目就必定处在不断的变化之中。有些变化是不能向前兼容的。因此您必须认真思考安装程序设计上的问题，就是说让同一项目的不同版本的代码安装后可以共存在一个系统中。这个问题对库项目的发布尤为重要，因为您不能指望所有基于这个库的应用程序都会紧跟您的API接口规范的后尘。
6.好的文档编写惯例
7.好的沟通方式
建一个与项目相关的网站
如果您想围绕项目建立一个用户、开发者的网上社区的话，最好应该建一个网站。一个标准的项目网站一般包括如下内容：
项目的特点（为何要有这个项目，谁会对此项目感兴趣）。
下载项目源代码的地方。
指明如何加入项目相关的邮件列表。
一个常见问题解答列表。
HTML格式的项目文档。
与项目相关或竞争的其他项目或网站的链接。
有的项目站点甚至还有指向源码结构树的匿名访问链接（便于跟踪项目进展）。
8.好的项目管理经验
关于基本开发模式的讨论和对“早发布常发布”的集市开发模式的论述请参考《大教堂和集市》一文。
关于心理动机、社群习俗和化解各种冲突的讨论请参阅《开拓智域》一文。
关于开源软件经济学基础和各种商业运作模式的讨论请阅读 《魔法大锅炉》一文。
需要指出的是这些文章并非自由软件开发的终极论断，不过他们都是经过深思熟虑后的思想结晶，还没有其他文章超越了他们的深度（文章的作者非常希望未来某一天有人超越他们）。
浙公网安备 33010602011771号