发版流程规范化

[liyongning]

版本

uni-app vue3

新功能描述
建议将发版流程规范化，避免出现版本号不符合规范和回退版本号的情况

现状及问题

查看 npm 版本号，会发现中间发生好几次版本号回退的情况。这几次回退的版本号都是不符合规范的版本号，而且其中可能携带了 bug，比如 @dcloudio/uni-cli-shared@3.0.0-alpha-3031120220208001 这个版本（目前出现的最高版本），其中 /uni-cli-shared/src/vite/features.ts 文件中有一个叫 initManifestFeature 的方法，其中有几行这样的代码：

if (command === 'build') {
    // TODO 需要预编译一遍？
    features.wxs = false;
    features.longpress = false;
}

这几行代码在 @dcloudio/uni-cli-shared@3.0.0-alpha-3030820220114011 中是被注掉的。打开注释会导致如下问题：

<view :prop="msg" :change:prop="cb"></view>

上面的代码正常情况下是当 msg 改变后，change:prop 的回调会被执行。但是上面的注释内容打开后，就导致打包时（npm run build:h5) 将 __UNI_FEATURE_WXS__ 设置为了 false（打包后的 H5 关闭了 wxs 功能），导致 change:prop 的回调不会被调用。这就导致了部分利用了该特性的业务代码、工具库都无法正常运行，比如 ucharts，打包后的 H5 无法绘制图形，就因为 change:prop 没有执行。

而上面的问题官方其实已经解决了，但是解决的方案有问题。官方是通过回退版本号来解决的，这个操作就有很大的问题了，线上出现 bug，代码回退这没问题，但是版本号却不应该回退。理由如下：

作为已经发布的 alpha 版本开源框架，肯定会有大量的用户在用，特别还是用户量如此具体的 uni-app。而大家在使用时，比如 cli，package.json 中的安装包版本一般是这么写的：

{
  "@dcloudio/uni-app": "^3.0.0-alpha-3030820220114011"
}

这也是官方 cli 生成的代码中默认的写法。但是这样的写法遇到回退版本号的操作就会导致严重的问题，大家都知道，^ 符号会匹配最新的中版本号，也就是说，每次重新装包（npm i，自动化部署时也会有该操作）或者升级包时 (npm upgrade) 都会安装对应的最新的中版本号，这个操作放到这里就会安装 uni-app 目前有问题的最高版本 3.0.0-alpha-3031120220208001，就导致本地没问题（测试环境可能也正常），但是上线以后就报 bug 了，比如你的 ucharts 图表无法绘制出来。

尝试方案
这里正确的解决方案有两步：

1. 先将当前稳定版本的版本号更改为更高的版本号，然后紧急发一版，以解决一线用户业务上的问题
2. 通过自动化工具、脚本来规范发版流程

还有一个备选方案，就是将项目中的 ^ 符号去掉，这样就会安装固定版本。但是不推荐该方案，因为这需要所有用户更改自己项目的配置，然后重新上线。

补充信息
请问目前仓库中的 next 分支是最新的 uni-app vue3 的稳定版本吗？如果是，也同意该方案，我会提一个 PR，麻烦接受后尽快发版，当然该操作也可以由官方来进行，都行，麻烦回复一下。

[fxy060608]

已发布新版本：3.0.0-alpha-3031120220216001
截图所示的那几个版本，并非有意后退，而是发布了错误的版本号，发行有脚本命令，但版本号是人工确认的，因理解偏差导致了发布了错误的版本号，后续会规范发布流程

[liyongning]

已发布新版本：3.0.0-alpha-3031120220216001 截图所示的那几个版本，并非有意后退，而是发布了错误的版本号，发行有脚本命令，但版本号是人工确认的，因理解偏差导致了发布了错误的版本号，后续会规范发布流程

嗯，看到你的提交了，真效率，感谢🙏 🙏 ！！