LAVA-ODM-QA-036-V1.0 软件版本命名规则及发布流程规范-20131014
LAVA ODM 软件版本命名规则及发布流程规范
LAVA-ODM-QA-036-V1.0
更 改 记 录
版次 页次 日期 拟制人/更改人 变更内容 V1.0 共5页 2013-9-15 赵永波 初版发行
目 录
1.0 目的 (4)
2.0 适用范围 (4)
3.0 职责 (4)
4.0 定义 (4)
5.0 执行程序 (4)
6.0 附件清单 (5)
7.0 文件解释权限 (5)
8.0 文件有效期限 (5)
1.0目的
规范 LAVA 公司 ODM 业务的手机产品软件版本命名规则，软件发布要求，发布流程及定义流程中责任人。
2.0适用范围
所有LAVA 公司 ODM 业务的手机及其他产品，个别特殊产品另有要求的除外。
3.0职责
LAVA ODM PQE：负责更新和维护此文件，如有变更及时更新；对ODM发出要求且确保ODM提供的
相关资料是正确的。参与评审；确认生产和出货使用了正确的软件并监督执行，
发行软件跟踪清单给项目成员。
LAVA ODM OQC：根据PQE确认的信息，验货时核对实物是否符合确认的信息。
ODM 软件开发人员：负责确认及解bug；并参与评审。
印度项目部：接到ODM软件后，向印度软件部提供软件并发出测试要求及跟进测试进度；组织评
审；对软件是否可用做最后判决并把结果通知到各相关部分。统一对外及对内输
出要求，并确保正确执行；确认后提供相关信息给到质量部。
印度软件测试部：负责软件的测试，量产软件测试完成后正式通知到印度的项目部确认结果。
4.0定义
无
5.0执行程序
5.1 软件版本命名规则：
试产/量产软件命名规则：LAVA_机型名称_软件版本（用SXXX来表示，三位不够用，可以用四位）_软
件build的日期,每更新一次，软件版本和build的日期必须变更，如：LAVA_KKT34A_S101_20120403机型
名称中带“+”用字母“A”表示。
售后软件命名规则：同最新的量产软件版本。
软件命名规则中各位数的含义如下：
S102，S203，S304，S305，S406，S407则说明：
该项目名称是KKT40+；共用4个硬件版本，软件共发行了8个版本。其中， 第一个硬件版本共发行了2个软件版本； 第二个硬件版本发行了1个软件版本； 第三个硬件版本共发行了2个软件版本； 第四个硬件版本发行了3个版本。
假如到第四个硬件版本时但发现第三个硬件版本中的软件有bug 需要修复时，则出的软件版本为S309，其他的依次原理来定义。 特别提醒：硬件（含结构）变更导致软件不兼容的情况下，才会需要变更硬件版本号，并在release
note 中注明对应关系此变更从该文件生效后的新项目开始执行，
对于在此之前已经开启的项目，如果软件未最终确定，可以按此要求执行的话，也按此执行，如不能则
可不按此要求执行。
5.2 软件发布要求：
5.2.1 发软件时必须带Release notes 文档且和软件实体打包一起发，文件名称同软件名称保持一致；release
notes 需保留之前的历史,模板参考附件；售后软件发布的时间和其他要求：在第一版量产软件确认后的7天内发布第一版本的售后软件，在量产软件的基础上去掉销量统计功能，并解决量产软件上要求解决的bug ；后续每更新一次量产软件，必须出对应的售后软件，时间相差最多不超过7天，如有把握可以同量产软件一起出。
5.2.2 软件发布必须但不限于知会项目组的软件人员，项目经理和PQE 。
5.3 软件的确认：
由项目组成员参与评审，项目经理综合评估结果决定是否可用，基于这个结果软件测试部出ECN ，会签后，由PM 并知会整个团队及工厂，及具体告知导入时间或者可使用的数量。
6.0 附件清单
无
7.0 文件解释权限
LAVA ODM 品质部
8.0 文件有效期限
本规定自发布之日起生效执行，至下次修正发布之日作废失效。
------------------------------------------END------------------------------------------
开始
发出软件给到印度软件测试团队
印度项目团队试用
印度项目经理输出确认结果ODM 正式发行导入生产
结束
OK
LAVA PQE 更新软件清单输出项目成员印度软件测试输出测试结果/中国&印度团队输出试用反馈结果
软件开发流程管理制度
软件开发流程管理制度 （讨论稿） 为加强对定制软件开发工作管理，缩短开发周期，提高软件开发质量，降低开发成本，提高定开发效率和效益，特制定软件开发流程管理制度。 第一章、总则 为保证日常工作正常有序的进行，让开发中各个环境更紧凑，更可控，需要尽可能实现项目管理的正规化，工作过程的流程化，以便提高软件质量，按期交付。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 第二章、阶段成果 根据软件工程的过程，制定以下工作流程，并规定了各个重要环节需要提交的交付物。各阶段需提交的文档： 1、立项：项目申请表，软件需求报告或设计方案。 2、需求分析：项目研发主计划、需求规格说明书 3、总体设计：概要设计说明书或功能模块描述 4、详细设计：详细设计说明书，包括软件接口说明、单元测试计
划。 5、软件实现：软件功能说明、源代码说明或者注释 6、产品测试：测试报告 7、产品发布：产品说明书、使用手册 8、产品维护：问题反馈记录 9、项目总结：提交客户方的项目总结和公司项目汇报的PPT。软件过程成果表：
第三章、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写，系统总体设计的编写；开发阶段完成设计文档的编写，代码的编写、代码的维护。测试阶段完成系统的测试，测试文档及其他材料。通过逐渐的调整岗位，明确工作职责，逐步实现项目经理，软件设计师，程序员，测试工程师的岗位设置。
版本发布命名规范
1. 1.版本命名规范 软件版本号有四部分组成，第一部分为主版本号，第二部分为次版本号，第三部分为修订版 本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有五种，分别为base、alpha、beta 、RC 、 release 2. 2.软件版本阶段说明 Base：此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。 Alpha ：软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。测试人员提交Bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可将软件版本标注为alpha版。 Beta ：该版本相对于Alpha 版已经有了很大的进步，消除了严重错误，但还需要经过多次测试来进一步消除，此版本主要的修改对象是软件的UI。 修改的的Bug 经测试人员测试确认后可发布到外网上，此时可将软件版本标注为 beta版。 RC ：该版本已经相当成熟了，基本上不存在导致错误的Bug，与即将发行的正式版本相差无几。 Release：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式的版本，是最终交付用户使用的一个版本。该版本有时也称标准版。 3. 3.版本号修改规则
（1）主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化。此版本号由项目决定是否修改。 （2）次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。 （3）修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩充，要经常发布修订版，修复一个严重 Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 （4）日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。 （5）希腊字母版本号：此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。 4.版本发布周期 （1）非紧急情况：首先由测试人员测试并提交Bug，其次开发人员会尽量在当天修复Bug并在第二天发布该版本的alpha版，然后由测试人员测试验证关闭Bug之后在第三天会发布该版本的 beta 版。 紧急情况：如果Bug比较紧急可跳过一般流程，由开发人员尽快修复Bug，测试确认之后直接发布该版本的 beta版。 5. 5 5 .版本号修改举例说明 如此时版本号为：1.0.0.0321_alpha ，此时为内部测试阶段 （1）开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为： 1.0.0.0321_beta ，如当前日期跟上一个版本号的日期不一样，版本号可改 为：1.0.0.0322_beta。 （2）如果修复了一些重大Bug 并按照流程发布到外网时就可发布一个修订版，如1.0.1.0322_beta，日期为发布的当前日期。
版本控制流程规范V完整版
版本控制流程规范V HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】
版本控制流程规范文档 目录 一、编写目的 本文档主要目的是规范配置管理活动的过程，阐述了在项目开发、测试、实施的过程中SVN库的组成和使用规约，指导使用者正确地操作SVN 库，以保证项目中所产生的代码、文档各版本之间完整性、可追踪性和一致性。 二、适用范围 该规范适用于公司内部所有项目的配置管理过程。 三、环境资源 在整个项目过程或产品生命周期中,选择SVN作为配置管理工具。
四、职责 五、规范 1，用户命名及权限配置 1)SVN用户命名 项目组成员在各自的PC上安装SVN客户端，根据配置管 理员所分配的用户和权限登录配置库进行各项配置管理活 动。 初始用户命名规则： 用户名：公司邮箱@前的部分
密码：手机号后6位 2)访问约定 为了保证各个项目组开发成果的安全性，以项目为单位， 进行了精确权限划分，使得成员只能操作该项目组内的配 置项。 内网访问svn资源库地址： svn: ... /svn/项目名称 3)权限管理 各个项目组成员只能访问、操作各自的项目库，并具有特 定文件区域的读、写权限，配置管理员统一分配和管理权 限。 2，SVN库的划分 根据公司的项目，采用项目名—分区名—版本名—的主结构进行管理。 1)版本库名 根据项目名称由项目经理与配置管理员共同设定。各项目 统一建立2层目录，子目录根据实际情况建立。 2)文件结构 a)工作区：按版本存放提交测试阶段的相关程序、文档等 开发：开发相关 测试：测试相关
软件版本管理规范标准[详]
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划
上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）
软件项目版本号的命名规则及格式2016
软件项目版本号的命名规则及格式 版本控制比较普遍的3 种命名格式: 一、GNU 风格的版本号命名格式: 主版本号 . 子版本号[. 修正版本号[. 编译版本号]] Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Nu mber]] 示例: 1.2.1, 2.0, 5.0.0 build-13124 二、Windows 风格的版本号命名格式: 主版本号 . 子版本号[ 修正版本号[. 编译版本号]] Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Nu mber]] 示例: 1.21, 2.0 三、.Net Framework 风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]] Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Nu mber]] 版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。所有定义的部分都必须是大于或等于0 的整数。 应根据下面的约定使用这些部分： Major ：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。 Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。 Build ：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。 Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。 程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序(Hotfix) 更新。 版本号管理策略 一、GNU 风格的版本号管理策略：
APP版本命名规范
APP版本命名规范 2016/11/18 ALEX 1.版本号构成说明 APP版本号由四部分组成，中间用英文字符“.”连接。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号加希腊字母版本号。版本号为阿拉伯数字0-9，希腊字母版本号共有五种，分别为base、alpha、beta、RC、release。 举例：V1.2.3.20161118.beta。其中1代表主版本号，2代表次版本号，3代表修订版本号，20161118代表日期版本号，beta代表希腊字母版本号。 2.APP版本阶段说明 A.Base：此版本表示该APP仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是 页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。 B.Alpha：APP的测试版本。该APP在此阶段以实现功能为主，通常只在APP开发者内部交 流。一般而言，该版本bug较多，需要继续修改。测试人员提交bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可将APP版本标注为alpha版。 C.Beta：该版本相对于Alpha版已经有了很大的进步，消除了严重错误，但还需要经过多次 测试来进一步消除，此版本主要的修改对象是APP的UI。修改的的bug经测试人员测试确认后可发布到外网上，此时可将APP版本标注为beta版。 D.RC：该版本已经相当成熟，基本上不存在导致错误的bug，与正式版本相差无几。 E.Release：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式 的版本，是最终交付用户使用的一个版本。该版本有时也称标准版。 3.版本号修改规则 初始版本号：V1.0.0.20161117.alpha，此时为内部测试阶段。 A.希腊字母版本号：此版本号用于标注当前版本APP处于哪个开发阶段，当APP进入到另一 个阶段时需要修改此版本号。此版本号由项目决定是否修改。
软件版本管理规范标准
软件版本管理规 V1.0.0 文档版本变更记录：
目录 前言 (3) 1 围 (4) 2 术语和定义 (4) 2.1 软件 (4) 2.2 产品软件 (4) 2.3 演示软件 (4) 3 软件版本命名规则 (4) 3.1 软件版本命名组成 (4) 3.2 产品软件版本命名 (4) 3.3 演示软件版本命名 (5) 3.4 正式版本号的升级规则 (6) 3.4.1 软件版本升级规则 (6) 3.4.2 演示版本升级规则 (6) 3.5 版本的安装文件命名规则及存放路径 (6) 4 软件版本发布流程 (7) 5 管理条例 (7) 6 附录 (7)
前言 为规部门产品软件版本的管理与控制，保证产品版本的有效与质量，制定本标准。本标准由移动金融事业部拟制。 本标准于2015年6月首次发布。
软件版本管理规定 1围 本标准规定了移动银行事业部产品软件版本的控制与管理。 本标准适用于移动银行事业部产品软件版本的控制与管理。 2术语和定义 下列定义适用于本标准。 2.1软件 指与产品相关的所有软件，可以分为产品软件和演示软件。 2.2产品软件 已签订合同，有明确交付日期的产品。 2.3演示软件 处于研发阶段，并未正式投入生产的应用。 3软件版本命名规则 3.1软件版本命名组成 产品的正式软件版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 产品的演示版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 3.2产品软件版本命名 产品软件版本的命名规则如下所示：
【项目管理知识】软件项目版本号的命名规则及格式介绍
软件项目版本号的命名规则及格式介绍 版本控制比较普遍的3种命名格式: 一、GNU风格的版本号命名格式: 主版本号.子版本号[.修正版本号[.编译版本号]] 英文对 照:Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Numb er]] 示例:1.2.1,2.0,5.0.0build-13124 二、Windows风格的版本号命名格式: 主版本号.子版本号[修正版本号[.编译版本号]] 英文对 照:Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Numb er]] 示例:1.21,2.0 三、.NetFramework风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]] 英文对 照:Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Numb er]]
版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订 号。主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果 定义了修订号部分，则内部版本号就是必选的。所有定义的部分都必须是大于 或等于0的整数。 应根据下面的约定使用这些部分： Major：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于 对产品的大量重写，这些重写使得无法实现向后兼容性。 Minor：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示 显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后 兼容的新版本。 Build：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处 理器、平台或编译器的情况。 Revision：名称、主版本号和次版本号都相同但修订号不同的程序集应是完 全可互换的。这适用于修复以前发布的程序集中的安全漏洞。 程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修 补程序(Hotfix)更新。 版本号管理策略 一、GNU风格的版本号管理策略： 1．项目初版本时,版本号可以为0.1或0.1.0,也可以为1.0或1.0.0,如果你为人很低调,我想你会选择那个主版本号为0的方式;
软件版本命名规则
空蓝 忍耐 我很幸运！: ) 主页博客相册|个人档案|好友 查看文章 【规范】软件版本命名规范 2010-02-21 18:01 一、软件版本命名规范 1. 软件版本阶段说明 * Base 版: 此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。 * Alpha 版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug 较多，需要继续修改。 * Beta 版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI 。 * RC 版: 该版本已经相当成熟了，基本上不存在导致错误的BUG ，与即将发行的正式版相差无几。 * Release 版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release 不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。 2. 版本命名规范 软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base 、alpha 、beta 、RC 、release 。例如：1.1.1.051021_beta 。 # 版本号定修改规则： * 主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。 * 子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。 * 阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 * 日期版本号(051021):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。 * 希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。 # 文件命名规范 文件名称由四部分组成：第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀，例如：项目外 包平台测试报告1.1.1.051021_beta_b.xls ，此文件为项目外包平台的测试报告文档，版本号为：1.1.1.051021_beta 。 3. 版本的协同作业 如果是同一版本同一阶段的文件修改过两次以上，则在阶段标识后面加以数字标识，每次修改数字加1，项目外包平台测试报告 1.1.1.051021_beta_b1.xls 当有多人同时提交同一份文件时，可以在阶段标识的后面加入人名或缩写来区别，例如：项目外包平台测试报告 1.1.1.051021_beta_b_LiuQi.xls 。当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别，例如：项目外包平台测试 报告 1.1.1.051021_beta_b_LiuQi 2.xls 关于软件版本划分的一些知识 | | | | 激活我的百度空间百度空间百度首页 lmhytr
新品发布会的流程安排
新品发布会的流程安排-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
新品发布会的流程安排 一、新品发布会会议议程安排 1、14:00-14:30 特邀嘉宾、来宾、媒体签到(赠送礼物) 2、14:00-14:30 引导特邀嘉宾、来宾、媒体就座(进场背景音乐) 3、14:30-15:OO 播放企业宜传片 4、15:00-15:05 主持人宣布新品发布会开始并介绍公司领导特邀嘉宾、来宾与媒体 5、15.05:15:10 主办公司总经理致辞欢迎 6、16:45-17:30 记者来宾提问，市场营销负责人、项目负责人、研究所领导和公司领导作答; 来宾自由讨论。 7、17:30 会议结束，安排来宾退场，指引转至用餐区，请媒体记者稍侯 8、17:30-17:45 研究所领导和市场营销负责人和媒体详细交流 9、17:45 与媒体交流结束，安排媒体退场，指引转至用餐区 10、17:45-20:00 共进晚餐
（以上时间及流程安排仅供参考，可根据实际情况安排） 二、场地布置布展 1、酒店正门大堂内，接待人员佩带单位绶带迎宾，设标明新品发布会场，就餐签到地点的指示牌。 2、宾客接待台，设接待人员两名，登记来宾和发放会议标准资料袋和参会证企画册，并配二名礼仪向导。 3、酒店门口和会仪厅门口各摆放X展架多个。 4、巨型唢绘做主会场背景墙，采访区背景墙舞台一旁区域为产品展架区、新闻采访区，演讲台正面贴中吴L0G0，上面摆笔记本电脑、麦克风、鲜花。 5、会场演讲台两侧摆放花篮各两个，走廊前台两旁X 展架。 6、主席台放嘉宾名片座，桌上摆茶杯和纯净水，文件夹DM封尾页，贵宾名签。 7、企业宣传片或纪录片以及产品宣传幻灯片等视听材料。 8、调试好音响设备，指定好录像人员。 三、参会应邀人员
软件版本命名规范
软件版本命名规范(如1、0、0、1各代表什么意思) 1、软件版本阶段说明 * Base版: 此版本表示该软件仅仅就是一个假页面链接,通常包括所有的功能与页面布局,但就是页面中的功能都没有做完整的实现,只就是做为整体网站的一个基础架构。 * Alpha版: 此版本表示该软件在此阶段主要就是以实现软件功能为主,通常只在软件开发者内部交流,一般而言,该版本软件的Bug较多,需要继续修改。 * Beta版: 该版本相对于α版已有了很大的改进,消除了严重的错误,但还就是存在着一些缺陷,需要经过多次测试来进一步消除,此版本主要的修改对像就是软件的UI。 * RC版: 该版本已经相当成熟了,基本上不存在导致错误的BUG,与即将发行的正式版相差无几。 * Release版: 该版本意味“最终版本”,在前面版本的一系列测试版之后,终归会有一个正式版本,就是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下,Release不会以单词形式出现在软件封面上,取而代之的就是符号(Ｒ)。 2、版本命名规范 软件版本号由四部分组成,第一个1为主版本号,第二个1为子版本号,第三个1为阶段版本号,第四部分为日期版本号加希腊字母版本号,希腊字母版本号共有5种,分别为:base、alpha、beta、RC、release。例如:1、1、1、051021_beta。 # 版本号定修改规则: * 主版本号(1):当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化。此版本号由项目决定就是否修改。 * 子版本号(1):当功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定就是否修改。 * 阶段版本号(1):一般就是 Bug 修复或就是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定就是否修改。 * 日期版本号(051021):用于记录修改项目的当前日期,每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定就是否修改。 * 希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段,当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定就是否修改。 # 文件命名规范 文件名称由四部分组成:第一部分为项目名称,第二部分为文件的描述,第三部分为当前软件的版本号,第四部分为文件阶段标识加文件后缀,例如:项目外包平台测试报告1、1、1、 051021_beta_b、xls,此文件为项目外包平台的测试报告文档,版本号为:1、1、1、051021_beta。 3、如果就是同一版本同一阶段的文件修改过两次以上,则在阶段标识后面加以数字标识,每次修改数字加1,项目外包平台测试报告1、1、1、051021_beta_b1、xls 当有多人同时提交同一份文件时,可以在阶段标识的后面加入人名或缩写来区别,例如:项目外包平台测试报告 1、1、1、051021_beta_b_LiuQi、xls。当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别,例如:项目外包平台测试报告1、1、1、051021_beta_b_LiuQi2、xls
最新新品发布会的流程安排知识分享
新品发布会的流程安排 一、新品发布会会议议程安排 1、14:00-14:30 特邀嘉宾、来宾、媒体签到(赠送礼物) 2、14:00-14:30 引导特邀嘉宾、来宾、媒体就座(进场背景音乐) 3、14:30-15:OO 播放企业宜传片 4、15:00-15:05 主持人宣布新品发布会开始并介绍公司领导特邀嘉宾、来宾与媒体 5、15.05:15:10 主办公司总经理致辞欢迎 6、16:45-17:30 记者来宾提问，市场营销负责人、项目负责人、研究所领导和公司领导作答; 来宾自由讨论。 7、17:30 会议结束，安排来宾退场，指引转至用餐区，请媒体记者稍侯 8、17:30-17:45 研究所领导和市场营销负责人和媒体详细交流 9、17:45 与媒体交流结束，安排媒体退场，指引转至用餐区 10、17:45-20:00 共进晚餐
（以上时间及流程安排仅供参考，可根据实际情况安排） 二、场地布置布展 1、酒店正门大堂内，接待人员佩带单位绶带迎宾，设标明新品发布会场，就餐签到地点的指示牌。 2、宾客接待台，设接待人员两名，登记来宾和发放会议标准资料袋和参会证企画册，并配二名礼仪向导。 3、酒店门口和会仪厅门口各摆放X展架多个。 4、巨型唢绘做主会场背景墙，采访区背景墙舞台一旁区域为产品展架区、新闻采访区，演讲台正面贴中吴L0G0，上面摆笔记本电脑、麦克风、鲜花。 5、会场演讲台两侧摆放花篮各两个，走廊前台两旁X 展架。 6、主席台放嘉宾名片座，桌上摆茶杯和纯净水，文件夹DM封尾页，贵宾名签。 7、企业宣传片或纪录片以及产品宣传幻灯片等视听材料。 8、调试好音响设备，指定好录像人员。 三、参会应邀人员
软件产品发布流程
严格按照软件产品发布流程发布软件版本是建立和完善软件产品版本控制,保证软件产品质量的关键过程 之一。 参与软件产品发布的人员主要是测试负责人和BM(Build Master)。 公司软件产品发布的规程如下: 1、发布准备。发布之前,所有程序freezed由测试人员进行确认测试;检查qcs系统内登记的所有bug都已经被fixed,或者遗留的bug不影响系统的使用,如果有严重bug未解决(级别为must fixed)不能发布;程序打包前做冒烟测试。 2、测试负责人编写release产品质量报告进行质量分析和总结。 3、源码、文档入库。源码包括数据库创建脚本(含静态数据)、编译构建脚本和所有源代码;文档包括需求、设计、测试文档,安装手册、使用手册、二次开发手册、产品介绍(ppt)、使用demo等。 4、BM进行程序打包;标记源码、文档版本tag。 5、BM填写发布基线通知并通知相关人员;BM经理对发布基线进行审计。 6、在qcs系统上新建产品发布计划,填写配置项,执行发布计划(发布产品)。 7、上传程序包、使用文档至download站点。 8、编写发布说明readme.txt(或者release note)。Readme的内容应该包括产品版本说明;产品概要介绍;本次发布包含的文件包、文档说明;本次发布包含或者新增的功能特性说明;遗留问题及影响说明;版权声明以及其他需要说明的事项。 9、正式发布通知。通知开发、测试、市场、销售各相关部门并附上产品发布说明和产品介绍。
10、后续工作。产品发布后,在使用过程中可能还会发现一些bug。在不影响正常使用的情况下,这些bug将在下一版本发布时解决;如果bug严重影响使用,必须打patch或者按照流程重新发布。 11、临时发布。软件产品未正式发布前,可能需要一个临时版本供开发人员或者用户应急使用,这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员;BM需要为源码、文档打tag标记。 软件产品发布后,即建立了一条发布基线。所有用户安装及二次开发必须在此基线上进行,开发人员不能直接从cvs或vss上check 代码编译交付用户使用或者进行二次开发。
产品发布会流程步骤
产品发布会流程步骤 导读：我根据大家的需要整理了一份关于《产品发布会流程步骤》的内容，具体内容：没有新闻的新闻发布会。有些企业似乎有开发布会的嗜好，很多时候，企业并没有重大的新闻，但为了保持一定的影响力，证明自己的存在，也要时不时地开个发布会。我给大家整理了关于，希望你们喜欢!...没有新闻的新闻发布会。有些企业似乎有开发布会的嗜好，很多时候，企业并没有重大的新闻，但为了保持一定的影响力，证明自己的存在，也要时不时地开个发布会。我给大家整理了关于，希望你们喜欢! 新闻发布会的标题选择 新闻发布会一般针对对企业意义重大，媒体感兴趣的事件举办。每个新闻发布会都会有一个名字，这个名字会打在关于新闻发布会的一切表现形式上，包括请柬、会议资料、会场布置、纪念品等。在选择新闻发布会的标题时，一般需要注意以下几点。 1、避免使用新闻发布会的字样。我国对新闻发布会是有严格申报、审批程序的，对企业而言，并没有必要如此烦琐，所以直接把发布会的名字定义为"**信息发布会"或"**媒体沟通会"即可。 2、最好在发布会的标题中说明发布会的主旨内容。如："某某企业2005新品发布信息发布会"。 3、通常情况下，需要打出会议举办的时间、地点和主办单位。这个可以在发布会主标题下以字体稍小的方式出现。 4、有时，可以为发布会选择一个具有象征意义的标题。这时，一般可
以采取主题加副题的方式。副题说明发布会的内容，主题表现企业想要表达的主要含义。如：海阔天空五星电器收购青岛雅泰信息发布会 新闻发布会的时间选择 新闻发布的时间通常也是决定新闻何时播出或刊出的时间。 因为多数平面媒体刊出新闻的时间是在获得信息的第二天，因此要把发布会的时间尽可能安排在周一、二、三的下午为宜，会议时间保证在1小时左右，这样可以相对保证发布会的现场效果和会后见报效果。 发布会应该尽量不选择在上午较早或晚上。部分主办者出于礼貌的考虑，有的希望可以与记者在发布会后共进午餐或晚餐，这并不可取。如果不是历时较长的邀请记者进行体验式的新闻发布会，一般不需要做类似的安排。 有一些以晚宴酒会形式举行的重大事件发布，也会邀请记者出席。但应把新闻发布的内容安排在最初的阶段，至少保证记者的采访工作可以比较早的结束，确保媒体次日发稿。 在时间选择上还要避开重要的政治事件和社会事件，媒体对这些事件的大篇幅报道任务，会冲淡企业新闻发布会的传播效果。 新闻发布会的地点安排 场地可以选择户外(事件发生的现场，便于摄影记者拍照)，也可以选择在室内。根据发布会规模的大小，室内发布会可以直接安排在企业的办公场所或者选择酒店。酒店有不同的星级，从企业形象的角度来说，重要的发布会宜选择五星级或四星级酒店。 酒店有不同的风格，不同的定位，选择酒店的风格要注意与发布会的内
软件系统命名规则
1、目的 本指导书是为软件配置管理而制定。其目的是使公司软件产品配置标识的命名规范化。 2、适用范围 适用于本公司所有软件产品的配置管理。 3、职责 4、控制内容 、软件配置标识的组成 、软件提供给用户的阶段产品和最终产品的配置标识由公司代码QW和以下五部分组成。 a、产品类别代码 b、产品（项目）标识或子系统标识 c、配置项标识 d、版本号 其一般形式为：QWa-bbbb-cc-dd 、软件开发过程中产生仅供公司或项目内部使用的配置项，其配置标识的一般形式为：bbcccccc-dd，其中，bb为产品（项目）标识缩写，cccccc为配置项标识，dd为版本号。 、部门代码 部门代码按《体系文件编号规定》条的规定控制。 、产品（项目）标识及其缩写 产品（项目）标识由反映产品或项目名称的4~5位拼音字母组成，前2位字母为其缩写。如DHMIS是杭州大和热磁电子有限公司管理信息系统的项目标识，而DH则为其缩写。 、子系统标识 子系统标识由2位产品（项目）标识缩写和2~3位子系统名拼音字母组成，其中第3、4两位为子系统标识缩写。如DHXS是大和项目销售子系统的标识，而XS是其缩写。 、配置项标识 、所述配置标识中的配置项标示：识（cc）如下表所
配置项标识（cc） 系统规格说明书FB 项目开发计划DP 软件需求规格说明书RS 概要设计说明书PD 详细设计说明书DD 用户手册UM 操作手册OM 源程序SP 、所述配置标识中的配置项标识（cccccc）有以下情况： a、配置项为数据项：配置标识由2位全局标识SY或子系统标识缩 写（局部数据）和3位数字码组成。 如SY001为001号全局数据的配置项标识 XS031为销售子系统031号数据的配置项标识。 b、配置项为数据流： 配置项标识由2位子系统标识缩写，2位数据流标识DF和2位数字码组成。 如ZCDF02为资财子系统02号数据流的配置项标识。 c、配置项为数据存储结构： 配置项标识由2位子系统标识缩写，2位数据存储标识DB和2位数字码组成。 如ZZDB01为制造子系统01号数据存储结构的配置项标识。 d、配置项为程序模块： 配置项标识由2位子系统标识缩写，程序模块标识M和2~3位数字码组成。 如XSM101为销售子系统101号程序模块的配置项标识。 e、配置项为存储媒体 配置项标识由2位产品（项目）标识缩写或子系统标识缩写，2
软件项目上线标准流程
项目上线部署发布流程
2017/9/14
一.目的 规范公司项目和产品的上线流程，建立和完善产品的版本控制，保证软件产品质量。二.适用范围 适用于公司所有项目和产品 三.职责分工 开发环境由开发人员内部负责（包括维护和管理开发分支和git代码库） 测试环境由测试人员负责 预热环境由运维人员负责 正式环境由运维人员负责 *数据库操作均由DBA统一负责(或运维人员) 四.发布流程 在已开发完毕的各系统正式部署生产环境前要严格按照以下流程进行上线前检查。 4.1.提交测试 ①开发人员在功能开发完毕后首先配置开发环境，并将系统部署至开发环境。在开发环境经过自测通过后提交测试代码，并开始撰写上线方案。(上线方案须包括新增的外部应用程序安装，应用程序部署顺序及应用关联性、是否关闭其他应用服务，数据库脚本，制定合理的上线时间，涉及的服务影响范围以及上线失败的回滚步骤。)并提交相关技术负责人审核，在审核过后邮件给相关测试人员。 ②测试人员根据模块功能文档并制定测试方案，测试用例，特别注意临界点测试方案。 ③测试人员通过自动化部署平台根据提供的分支号依照上线方案进行自动化部署，涉
及数据库操作可提请DBA操作。 ④记录各种数据测试结果及测试问题，并交由相关开发人员进行二次迭代处理，该点须交付测试结果报告。 ⑤内测完毕后交由相关业务及需求人员进行集成测试，并请测试人员记录测试结果及问题，交由相关开发人员进行再次迭代。该点须交付测试方案测试结果报告。 4.2.预热发布 ①测试人员在测试环境测试并跟踪修改bug达到上线标准（没有A、B级bug，C 级bug达到要求）时。开始部署预热环境，测试人员对现有功能在预热环境上进行验收测试（重新执行case）。紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决，确认达到上线标准。 ②如达到上线标准，测试人员发起邮件通知相关开发人员、产品人员，准备正式上线发布流程。 4.3.正式上线 ①在测试人员确认项目具备上线条件下，正式上线前，开发负责人须发起部署大会，召集相关开发人员、测试人员、产品人员、运维人员讨论此次部署事项(介绍项目的相应负责人员，数据库脚本执行，部署顺序，应用程序关联，部署时间点，部署回滚方案，包括数据库回滚和应用程序回滚)，最后生成会议纪要并发送邮件。 ②确认上线之后，测试人员邮件上线方案，数据库脚本，应用分支号给运维人员及DBA，DBA应提前执行数据库脚本，应用部署须通过自动化部署平台进行部署，部署系统应在应用系统中记录当前分支号，以便后续应用回滚使用。在部署中出现错误，及时通知相关开发人员。如若问题不能在计划内时间解决，执行回滚方案。 ③运维，DBA在操作完成时均需要回复邮件，并说明操作步骤结果。 ④发布完成后运维人员回复邮件通知测试人员、业务及需求人员进行线上测试。测试结果及问题, 提交至开发人员。如若出现问题不能在计划内时间解决，执行回滚方案，并进行迭代改进。 ⑤紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决。测试通
软件版本定义规则
软件版本定义规则 1引言 1.1编写目的 本文档作为本公司开发部测试部各项目组在进行软件设计、开发、测试时进行版本定义的指导性规则。 1.2定义和限制 软件版本号为形如A.B.C.D的由”.”所间隔开的4段字符组成。其中A、B、C段为从0开始的整数，D段为从0开始的整数或者整数加英文字符的形式。 2定义规则 在任何项目中，符合以下条件的模块需要独立维护版本： ?客户端和服务器端程序需要分开进行版本维护； ?可以独立运行并完成主要设计功能的模块； ?完成某些特定功能的接口程序或模块； ?其他必要的模块 2.1何时更改 在项目进行到以下进程时，需要更改软件版本号： ?测试中FIX了部分缺陷需要提交测试时； ?公开发布或者需要提交给用户时； ?增加或更改了系统需求，软件重新进行开发时； ?更改了系统的设计框架、重新进行开发时； 2.2如何更改 ?普通项目的所有模块初始软件版本号为0.0.0.1，如是从原有系统上升级或其他特殊原因可更改为其他初始版本号。 ?在每次提交测试时，需要更改软件版本号的D段，从1开始递增，特殊情况时可在D段整数后面增加英文字符作为标识。 ?每次公开发布或者提交给用户时，需要更改软件版本号的C段，从0开始递增； 同时将D段归0。因此所有D段为0的版本应该都是公开发布版本。 ?在原有总体设计上增加部分系统需求时，需要更改软件版本号的B段，从0开始递增，同时将C、D段归0。
?总体设计上有更改或者主要的功能模块设计上有变化，则可以更改软件版本号的A 段，从0开始递增，同时将B、C、D段归0。 规则表如下： 示例： ?假设原有版本为1.3.1.6， ?在下次提交新的测试版本时，版本号应升级为1.3.1.7； ? 1.3.1.7测试通过后需要对用户发布，则应该将版本升级为1.3.2.0； ?此时又修改了部分测试中发现的缺陷，并重新提交测试时，版本号应该升级为1.3.2.1； ?再次重新提交测试的版本号应该为1.3.2.2； ?如果用户经过试用，提交了部分新的需求，经过我们的重新修改部分编码，再次提交测 试，则测试时的版本号应该升级为1.4.0.1； ?测试通过后提交给用户的版本号应该为1.4.1.0； ?如果由于设计上的缺陷，系统需要重新设计和编码，进行了比较大的改动，并提交测试， 则测试时的版本号应该升级为2.0.0.1。
软件版本管理文档
文档编号： 编制：杨忠林 审核: 批准: 目录
1引言 (3) 目的 (3) 范围 (3) 术语定义 (3) 版序控制记录 (4) 版本更新记录 (4) 2版本管理 (4) 流程图 (4) 版本命名 (7) 外部版本命名说明 (7) 内部版本命名说明 (7) 内外部版本的关系 (7) 版本升级 (7) 版本升级原则 (7) 新版本的发布 (8) 目录结构 (8) 文档的存放 (9) 文本文件的存放 (9) 源代码的存放 (9) 发行文档的存放 (9) 权限控制管理 (10) 3备份管理 (10) 源文件备份 (10) 库文件备份 (10) 4用户版本管理 (10) 5版本工具的使用 (11) 配置管理工具 (11) SVN的使用 (11) 常用命令 (11) 简单操作 (12) 版本分支管理 (12)
1引言 1.1目的 本文档是为规范xxxx科技有限公司软件版本管理而制定的。 1.2范围 本文档为系统软件开发部版本管理员提供有关版本管理规范的相关内容，包括：版本标识方法 软件系统数据的存放 文档的修改控制 文档的备份制度 1.3术语定义 SVN SVN是一个开源的版本控制系统 Subversion 的简称 文档 一种数据媒体和其上所记录的数据。 配置管理 标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 软件配置 软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。 基线 软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，使之便于检验和肯定阶段成果。
软件项目版本号的命名规则及格式
原文出处：https://www.wendangku.net/doc/a611725907.html,/mini_snow/archive/2009/08/19/4462795.aspx 版本控制比较普遍的3 种命名格式: 一、GNU 风格的版本号命名格式: 主版本号 . 子版本号[. 修正版本号[. 编译版本号]] Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Nu mber]] 示例: 1.2.1, 2.0, 5.0.0 build-13124 二、Windows 风格的版本号命名格式: 主版本号 . 子版本号[ 修正版本号[. 编译版本号]] Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Num ber]] 示例: 1.21, 2.0 三、.Net Framework 风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]] Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Nu mber]] 版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。所有定义的部分都必须是大于或等于0 的整数。 应根据下面的约定使用这些部分： Major ：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。 Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。 Build ：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。 Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。 程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序(Hotfix) 更新。 版本号管理策略 一、GNU 风格的版本号管理策略：