search

NXT-FE / blog

能效通前端团队博客
MIT License
4 stars 0 forks source link

版本管理讨论 #3

Open pengkobe opened 7 years ago

pengkobe commented 7 years ago

发布说明

由于之前版本号管理较为混乱，各种版本到处跑，需要统一进行管理。

发布内容

  1. 难点
    • 各种后台数据接口测试
    • 更新的兼容问题测试
  2. 发布内容
    • 升级内容( 大的更改/新增功能/bug修复 )
    • 升级提醒( 钉钉/微信群/App内通知 )
    • 小版本则热更新，
      • 频繁发布运营成本较大( 外网运营客户端版本最多不要超过4个 )
      • 用户不喜欢频繁升级

版本号管理

采用格式为 主版本.子版本号.修正版本号

  1. 项目初版本时，版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0，暂定主版本号为 0 的方式
  2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1
  3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0
  4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1
  5. ~编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制(暂不支持)~

版本名称

暂定 3 个版本名称:

  1. α（alphal） 内部测试版

    α版，此版本表示该软件仅仅是一个初步完成品，通常只在软件开发者内部交流，也有很少一部分发布给专业测试人员。

  2. β（beta）外部测试版

    该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模的发布测试来进一步消除。用户可从相关的站点下载。通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改。该版本也不适合一般用户安装。

  3. γ（gamma）版

    该版本已经相当成熟了，与即将发行的正式版相差无几，如果用户实在等不及了，可以装上一试。

参考

文档: http://www.cnblogs.com/sdjxcolin/archive/2007/07/02/803376.html 选用其中介绍的 GNU 风格

pengkobe commented 7 years ago

开发与发布

主分支（Trunk/Master ）

主分支用来进行大版本的发布

Develop 分支

日常开发协作

架构性的改变，建议在本分支进行处理。

功能（feature）分支

从开发 Develop 分支拉取，用 feature-* 的形式命名。

为了避免分支融合处理困难，建议做好文件夹与文件划分。

预发布（release）分支

从 Develop 分支拉取，发布正式版本之前（即合并到 Master 分支之前）, 预发布结束以后，必须合并进 Develop 和 Master 分支。由于预发布分支只是起临时性发布的作用，合并到 Develop 和 Master 之后需进行删除。

在此分支单独的测试与修复不会影响 Develop 分支上功能的开发。

修补bug（fixbug）分支

修补 bug 分支是从 Master 分支上面分出来的。修补结束以后，再合并进 Master 和 Develop 分支。它的命名，可以采用fixbug-*的形式。

关于 H5

H5 分支比较难于维护，发布时需要修改比较多的内容

涉及到第三方时