软件版本发布规则
前言：
从网上找到的有关软件发布时候，如何命名的相关规则。虽然你可以对自己发布的软件随便起名，但尊循一定规则，还是非常有交流。
第一篇文章：
1 版本类型
1.1 正式版本
Enhance：增强版或者加强版 属于正式版
Full version：完全版 属于正式版
Release：发行版，有时间限制
Upgrade：升级版
Retail：零售版
Plus：增强版，不过这种大部分是在程序界面及多媒体功能上增强。
1.2 测试版本
Alphal：内部测试版
Beta：外部测试版
M 版： Milestone，意思是每个开发阶段的终结点的里程碑版本
Trail：试用版（含有某些限制，如时间、功能，注册后也有可能变为正式版）
RC版：Release Candidate，意思是发布倒计时，该版本已经完成全部功能并清除大部分的BUG。到了这个阶段只会除BUG，不会对软件做任何大的更改。
RTM版：Release To Manufactur，意思是发布到生产商，这基本就是最终的版本
GA版：Generally Available, 最终版
1.3 产品版本
Shareware：共享版
Free：自由版
Cardware：属共享软件的一种，只要给作者回复一封电邮或明信片即可。（有的作者并由此提供注册码等），目前这种形式已不多见。
Demo：演示版
Preview：预览版
Corporation & Enterprise：企业版
Standard：标准版
Mini：迷你版(精简版)，只有最基本的功能
Premium：贵价版
Professional：专业版
Express：特别版
Deluxe：豪华版
Regged：已注册版
1.4 语言分类
CN：简体中文版
CHT：繁体中文版
EN：英文版
Multilanguage：多语言版
1.5 其他分类
Rip：是指从原版文件（一般是指光盘或光盘镜像文件）直接将有用的内容（核心内容）分离出来，剔除无用的文档，例如PDF说明文件啊，视频演示啊之类的东西，也可以算做是精简版吧…但主要内容功能是一点也不能缺少的！另：DVDrip是指将视频和音频直接从DVD光盘里以文件方式分离出来。
OEM版：Original Equipment Manufacturer，意思是提供给电脑生产厂的版本
FPP版：Full Packaged Product (FPP)–Retail，就是零售版（盒装软件），这种产品的光盘的卷标都带有“FPP“字样
VLO版：Volume Licensing for Organizations ，团体批量许可证（大量采购授权合约），这是为团体购买而制定的一种优惠方式。
这种版本根据购买数量等又细分为以下5种版本：
开放式许可证--Open License
选择式许可证--Select License
企业协议--Enterprise Agreement
企业订阅协议--Enterprise Subscription Agreement
学术教育许可证--Academic Volume Licensing
2 版本编号
2.1 编号句法x.y.z
X：主版本号，用来表示提供给客户的产品功能的主要增强。在一个极端的例子中，主版本号的上升用来说明产品现在已经拥有了一个全新的功能类。从市场和许可权的角度来看，主版本号的升级相当于购买一个完全独立的产品。从开发者角度来看，一个主版本号的迭代差不多总是反映了一个新的独立分支或是其主干还可以延续主版本的生命期。
Y：特征版本号，用来表示产品新增了一些特征，或者是在原来文档中描述的特征上作了重要的修改。用来确定特征版本号什么时候需要修改的一个衡量标准就是产品功能说明书。产品的特征版本升级是在主版本之间保持产品竞争力的一种重要机制。
Z：缺陷修复版本号，用来表示在该版本上所做的缺陷维护行为的等级。版修复版本是稳定市场和最小化客户技术支持费用负担的一种重要机制。
2.2 支持α和β发布的编号句法x.y.z[A|B]
A：表示是α版本
B：表示是β版本
|：表示逻辑运算符“或”
[]：表示内部的元素是可选择的
说明：最后一个α或β发布之后，给正式客户发布版本来一个进位，以使其在“z”的位置出现一个0。如：正式客户发布2.2.6用版本号2.3.0来代替。
3 软件发布规则举例
3.1 简要描述
用于文件目录，压缩包等。
ProjectName-x.y.bYYYYMMDD[.n] (每日构建)
ProjectName-x.y.Mn (里程碑)
ProjectName-x.y.Betan (测试发布)
ProjectName-x.y.RCn (稳定化发布)
ProjectName-x.y.RTX[.Rn] (正式发布，或带更新包的正式发布)
3.2 详细描述
用于软件内部描述，如：“关于软件”。
ProjectName [V/版本]x.y.bn.un.[Mn/Betan/RCn/RTX[.Rn]].bYYYYMMDD[.n]
其文档版本发行规则：
DocumentName-Vx.y[.Rn] (发布，或带修订的发布)
简要描述举例：
xoWidgets的发布：
xoWidgets-1.0.b20080101
xoWidgets-1.0.b20080101.2 (当天第二次发布)
...
xoWidgets-1.0.M1 (里程碑版本1)
xoWidgets-1.0.b20080601
xoWidgets-1.0.b20080601.2 (当天第二次发布)
...
xoWidgets-1.0.M2 (里程碑版本2)
...
xoWidgets-1.0.Beta1 (测试版本1)
xoWidgets-1.0.Beta2 (测试版本2)
...
xoWidgets-1.0.RC1 (预发布版本1)
xoWidgets-1.0.RC2 (预发布版本2)
...
xoWidgets-1.0.RTX (交互的正式版本)
xoWidgets-1.0.RTX.R1 (交互的正式版本，带R1更新)
xoWidgets-1.0.RTX.R2 (交互的正式版本，带R2更新)
...
详细描述举例：
xoWidgets V1.0.2480.512.RTX.R2.b20081201
注：
(1) x - major，主要版本号
(2) y - minor，次要版本号 (偶数为稳定版本，奇数为开发版本)
(3) bn - build number，构建号
(4) un - update number，更新号
(5) YYYYMMDD - 年月日
(6) n - 递增的整数
第二篇文章：
优秀项目─档案─的命名惯例
用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.好的项目管理经验
关于基本开发模式的讨论和对“早发布常发布”的集市开发模式的论述请参考《大教堂和集市》一文。
关于心理动机、社群习俗和化解各种冲突的讨论请参阅《开拓智域》一文。
关于开源软件经济学基础和各种商业运作模式的讨论请阅读 《魔法大锅炉》一文。
需要指出的是这些文章并非自由软件开发的终极论断，不过他们都是经过深思熟虑后的思想结晶，还没有其他文章超越了他们的深度（文章的作者非常希望未来某一天有人超越他们）。
