关于发布的几点建议(from 4j)

[IceskYsl]

现在的apk是贴在eoeAndroid的帖子里，不方便用户下载，也不方便自动更新，太山寨，太不正规。关于发布我有点想法，在这儿念叨念叨。

发布在何处
仅发布在Google Play上，忽略其他所有的国内菜场。因为eoe并不是做推广，没必要各个菜场发布，那更加大了维护成本。为何是她，因为Google Play是最官方的。

可是有些人没有Google帐号，有些手机上没有Google Play？个人觉得这部分用户没有太大价值，可以直接忽略，还是上面那句话：eoe并不是做推广。

可是Google Play需要国外信用卡？这点应该难不倒eoe吧。

发布周期
周发布，每周五发布，小米这点蛮喜欢的。不过有个前提，更新点大于10个，就当周五发布；否则，下延到下个周五；如果下周五还不够10个，下延到下下周五。

Changelog
在Wiki中将每个版本的Changelog进行说明。
https://github.com/eoecn/android-app/wiki/Changelog

[IceskYsl]

我的意见是：

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

大家有其他建议没？

[IceskYsl]

@vincent4j 看上面的文字～

[vincent4j]

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

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

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

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

[vincent4j]

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

[IceskYsl]

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

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

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

[vincent4j]

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

[IceskYsl]

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

[haiyangjy]

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

[IceskYsl]

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

[vincent4j]

4j 木

[IceskYsl]

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