关于发布的几点建议(from 4j) about android-app HOT 11 OPEN

我的意见是：

1. 更新机制
   app内有版本升级的机制（目前用的是umeng的sdk），每次发布新版都在这推送给用户～
2. 发布的商店
   做一个标准版发google play软件商店，发布账号很容易搞定～
   再选择1个国内比较流行正规的商店保持及时发布（国内选哪个？）
3. 发布频率
   定期发布版本是个好办法，eoe之前做app的时候也是这个机制，一般是周五下班前出内测版本，小部分内部人内测，周一修复周末内测的问题，如果没大问题，周一发布；

4.版本规范
定期发布最好是有一个版本规范，eoe的经验是这样处理的
4.1 版本号和版本名 Ver1.0.0 => 100
4.2 版本名规范，采用VerX.Y.Z格式，定期发的版本是Y+1，遇到紧急bug需要修复的就发版本Z+1，除非有大版本的修改，否则不会修改X

大家有其他建议没？

from android-app.

@vincent4j 看上面的文字～

from android-app.

关于更新机制
其实我一直在纠结app内置更新机制的必要性，我觉得类似ios更新机制也未尝不可，仅仅app store更新。如此一来会省许多事，例如：服务器release版本的管理，启动流程中的release监测、下载安装都省了。当然，我似乎有些偏激，android内置更新机制好像是标配。

关于发布商店
国内，豌豆夹，其他一个不喜欢；豌豆夹国内遥遥领先。

关于发布版本号
完全同意，三级足够了。二级、三级+1，第一级不轻易变。

内测推送工具
追加一点，内测推送工具，ios我接触过testflight.com觉得还行，android就没接触过。

from android-app.

错啦，是这个链接：https://testflightapp.com/

from android-app.

内测推送工具这个简单，就是让一部分人先测试下，我们之前的做法是

1.umeng里管理渠道加一个内测渠道，之后更新可以先推送这个渠道的用户；
2.测试没问题了，再更新其他渠道

这里引申出另外一个问题，就是参与内测的用户可能需要内测几次，然后还和其他用户一起最终收到发布版，需要考虑的问题是版本号还版本名的规范~

from android-app.

我们以前都是同时做两版，尾数偶数为对外发布，奇数为内测。例如：1.2.0和1.2.1，如果存在问题fix之后重做成1.2.2和1.2.3。

from android-app.

稍微和前面的规范有些冲突

from android-app.

赞同国内豌豆荚~，其他的我也不喜欢~

from android-app.

@vincent4j @com360 这周准备发版本啦，上面的建议还有啥补充么？

from android-app.

4j 木

from android-app.

@vincent4j 内测的好像没定下来 ：0

from android-app.