2.2.0-RELEASE

版本同步

如果 npm install --registry=https://registry.npm.taobao.org 下载提示包版本不存在，那么点击我 在浏览器中打开，直到最后出现如下内容诶之才表示同步成功

...
Fail: [  ]
Sync gc-starter-ui-plus complete!

开发注意

• 配置别名可以解决引用加相对路径问题

import { pageMixins } from '../../../mixins/page'
// 修改之后
import { pageMixins } from 'gc-starter-ui-plus/mixins/page'

内存泄漏

内存泄漏解决方案 https://juejin.cn/post/6844903859354075144

版本定义

参考 https://semver.org/lang/zh-CN/spec/v2.0.0.html

向下兼容/向后兼容

此处的下以及后指的的过去的意思，是对已发布的旧版本进行兼容

向上兼容/向前兼容

此处的上以及前指的的未来的意思，是对以后版本的兼容

版本命名规范

版本号采用GNU风格命名方式：主版本号 . 子版本号 .修正版本号

• 主版本号：当你做了不兼容的 API 修改，不兼容的升级，如代码重构了、架构改变了，一般不需要修改
• 子版本号：当你做了向下兼容的功能性新增，新加了一个功能，可能需要改动一些文件，不影响已有功能的使用
• 修订号：当你做了向下兼容的问题修正，常见的bug修改，如果只是修订号的版本号改变，说明升级只需要修改版本号即可，项目中除了版本号以外的任何文件都不需要改动
• Alpha版：内测版。此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，或者专业测试人员测试用，一般而言，该版本软件的Bug较多，需要继续修改，在内部由专业测试人员进行测试时使用。
• Beta版：公测版。该版本相对于Alpha版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，如果紧急发布的一个未通过专业人员测试时，使用该版本号。
• RELEASE版：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版，通过了测试人员的全部测试。

命名规范案例

假设当前版本号为 1.2.0.RELEASE ，需要进行新内容开发(新需求、Bug等)，先基于1.2.0.RELEASE版本进行拉取一个分支，在新的分支上进行修改，根据将要开发的内容来决定分支的名称（在分支的最后需要加上-Dev来标识是开发分支），在内部进行测试时版本号命名规则为：主版本号.子版本号.修正版本号.时间（如: 20210710）+序号（当天的第N个版本，如:01、02、03...99）.Alpha，如2021年07月28日10:10:57 的第5个内部测试版本号为：1.2.1-2021012805-Alpha

假设上诉的bug正在修改中，此时用户要求尽快将Alpha版本进行升级使用，那么此时可以基于Alpha版本升级到Beta版本，如上诉 1.2.1-2021012805-Alpha 升级到 1.2.1-2021012801-Beta

版本发布的后续操作

• 当版本发布为 Beta 或 RELEASE 版本时，需要在gitlab上创建对应的标签，其中标签的名称和版本号保持完全一致
• gitlab打标签之后无法跟踪到代码的历史，所以还需要基于当前发布版本的开发分支创建新分支，并取名为当前发布的版本号

历史版本如何修改

对已发布的历史版本的bug修改，需要找到历史版本对应的源码，找到对应的分支，基于该分支创建新分支，在新分支上进行开发，测试。

当问题解决发布版本后，重复 【版本发布的后续操作】

自动发布CL

https://www.npmjs.com/package/semantic-release