最近兄弟部门部门做了比较大的调整。需要重新去定义产品，并做好产品的版本规划。从质量管理部OKR来分析，支持产品部门做好产品规划也是个优先任务。
（实际是以前没有明确，达成约定的版本规划和版本号定义…）
一个好的产品规划，除了对自己的产品有充分清晰地思考之外，还要兼顾外界的技术趋势、业界的动态、公司资源的考量。一定不能盲目地去加各种各样的需求，或者毫无目的地去做版本迭代。每个版本的需求一定都是基于产品目前的现状，市场的情况，最后基于产品发展的目的而去做的。
这是我总结的产品规划流程图：
因为对具体的产品业务不清楚，所以在职能擅长的范畴内，我会在产品版本命名规则，版本源码管理，版本扭转流程版本管理工具几个方面给与产品部门具体的支持和建议。
软件版本号的命名规范与原则为了在软件产品生命周期中更好的沟通和标记，很多公司对版本命名都有自己的一套规范，例如：
名称_主版本号.子版本号_SVN最后提交数
名称_主版本号.子版本号.阶段版本号_日期版本号加希腊字母版本号
名称_主版本号.子版本号_日期版本号加希腊字母版本号
我们应该对软件的版本号命名的规范和原则有一定的了解。
1、APP、软件的版本阶段
Alpha版：也叫α版，此版本主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
Beta版：此版本相对于α版已经有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
RC版：此版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几，测试人员基本通过的版本。
Release版：此版本意味着“最终版本”、“上线版本”，，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。
2、版本号的命名规范与原则
软件版本号有四部分组成：主版本号.子版本号.阶段版本号.日期版本号加希腊字母版本号。希腊字母版本号共有5种：base、alpha、beta、RC、Release。例如：1.0.0._base
通常，完全的版本号定义，分三项：主版本号.子版本号.阶段版本号,1.1.0
3、版本号修改规则
主版本号(1.x.x)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
子版本号(x.1.x)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
阶段版本号(x.x.1)：一般是Bug修复或是一些小的变动，要经常发布更新版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
日期版本号(x.x.x.)：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
希腊字母版本号(x.x.x.x_beta):：此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目经理决定是否修改。
、版本号的阶段标识
按照软件的研发过程，可以再将版本号进行相应的标注管理，但管理会变得过于复杂，视具体情况而定！
5、关于APP的版本管理
以Android为例，Android中有versionCode和versionName，他们分别所代表的意思如下：
verisonCode:内部版本号，必须是整型。用来区分版本的新旧，版本号越大，代表距当前越近的发布版本。给开发者内部使用的。
versionName:向用户展示的版本号，必须是字符串，这个版本号就是我们可以用来遵循规范的位置，可以作为版本比较的，判断是否需要提示更新、是否需要强制更新的依据。
使用SCM进行代码管理公司使用的SCM系统是SVN，以下结合SVN介绍怎样进行代码版本管理。
Subversion有一个很标准的目录结构，是这样的。比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是
svn://proj/
+-trunk+-branches+-tags
SVN有两种普遍的管理模式：
以Trunk做开发：
所有的开发都是基于trunk进行开发
时间区间(1)
(1)的起始时间是1.0.0开发的开始。
在(1)期间，没有任何用户使用1.0.0（还没有发布），开发人员直接在Trunk1.0.0上开发。
(1)的结束时间是1.0开发的结束时间。结束时发布1.0.0产品，在SVN上创建1.0.0Tag。这时Trunk1.0.0自动变成Trunk1.0.1。
时间区间(2)
(2)的起始时间是1.0.1开发的开始。
如果在(2)期间，用户报告1.0.0的Bug或者一些很急迫的功能要求，并且需要马上修复实现。那么：
在Tag：1.0.0_release基础上建立branches:1.0.0_bugfix，并且发布补丁包。
选择性的把dev_1.0.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）
(2)的结束时间是Turnk1.0.1开发的结束时间。结束时发布1.0.1产品。此时做以下事情：
将branches:1.0.0_bugfix的代码合并到Trunk1.0.1上。并且发布锁定Tag：1.0.1_release代码避免任何进一步的修改。
这时Trunk1.0.1自动变成Trunk1.0.2。
以分支做开发：
时间区间(1)
(1)的起始时间是1.0.0开发的开始。
在(1)期间，没有任何用户使用1.0.0（还没有发布），开发人员直接在Trunk1.0.0上开发。
(1)的结束时间是3.0开发的结束时间。结束时发布1.0.0产品，在SVN上创建1.0.0Tag，同时创建1.0.1Branch。这时Trunk1.0.0自动变成Trunk1.0.1。
时间区间(2)
(2)的起始时间是1.0.1开发的开始。
在(2)期间，因为有用户使用1.0.0，所以1.0.1所有的开发工作在Branch1.0.1上进行。
如果在(2)期间，用户报告1.0.0的Bug，并且需要马上修复。那么：
在1.0.1Trunk上对问题进行修复，并且发布补丁包。
将此改动合并到Branch1.0.1上。
(2)的结束时间是Branch1.0.1开发的结束时间。结束时发布1.0.1产品。此时做以下事情：
合并代码之前，在1.0.1Trunk上建立Tag，如：1.0.0_20。用来表示将1.0.1合并进来之前的代码。
将Branch1.0.1的代码合并到Trunk1.0.1上。并且锁定Trunk1.0.1代码避免任何进一步的修改。
从Trunk1.0.1上创建Branch1.0.2，用于进行Branch1.0.2的开发。
一些注意事项：
如果修复Bug，可以在Trunk或者Branch上做，但是一定要使用SubVersion的合并功能，而不是在Trunk和Branch上分别改两遍。如果改两遍，造成的结果是在要将Branch合并到Trunk上出现冲突。
如果有些核心数据结构的变动，将它放在小版本升级后的第一个迭代进行。避免对用户造成升级困难，或者用户需要重新装载所有数据。
合并代码的时候需要非常小心，保证Branch上的代码和合并以后Trunk的代码一样非常关键。如果不一样会造成这种情况：第一个从Branch上发布的产品没有问题；后来为了修复一个Bug，从Trunk上发布一个新版本后，出现了第一个发布没有出现的问题。
环境版本如何扭转项目因具体情况可能会出现多个测试环境进行维护的情况，这里以三套环境，N日为周期为例，该类情况可参考以下流程进行版本发布！
角色：开发，测试，开发负责人、版本负责人
环境：开发环境、测试环境、准生产环境
时间线
事务
T日
l9点版本负责人创建版本
l9-16点，开发人员开发功能，修改BUG（BUG解决关联禅道版本）
l16-18点，开发负责人确认版本信息（开发功能，测试注意事项，SVN模块最后version），提交版本负责人
l版本负责统计项目各产品版本信息（开发功能，测试注意事项，SVN模块最后version），驱动测试
T+N日
lT+1日9点，测试人员更新测试环境
lT+1日至T+N日15点，测试-测试版本（依据ＢＵＧ，功能，测试注意事项进行测试），提交ＢＵＧ（ＢＵＧ关联禅道版本）
lT+N日15..30-17点，确认测试环境版本信息，提供项目经理（邮件描述版本更新内容及测试结果）
l项目经理确认版本测试结果，驱动准生产环境进行更新
lT+N日17点-18点。冒烟准生产
T+N+1日
测试准生产
开发版本：
测试版本：
产品研发过程管理的方法和工具
使用Redmine进行研发管理，Redmine不仅可以用来做软件研发过程管理，而且可以用来管理非软件研发的项目。它给整个团队一个总览图，同时记录所有的细节。
朕觉得你写的好，要赏！
预览时标签不可点收录于合集#个上一篇下一篇