zoukankan      html  css  js  c++  java
  • 谈一谈APP版本号问题

    如题:谈一谈APP版本号问题

    为什么要谈这个问题,周五晚上11~12点,被微信点名,说APP有错,无效的版本号,商城无法下单。
    我正在准备收拾东西,周末回老家,结果看到这样问题,菊花一紧。
    我擦,我刚加的版本号检查,在加版本号检查前,我还跟统计的妹妹仔细核对了近半年来所有的版本号,怎么还会有问题。
    赶紧查,原来结果,看到了一个g1_2.5.5_65,在我的一再追问下说这个就是2.5.5的版本号。
    然后咱们来说一说为什么要加版本号检查,然后再说,为什么会加出问题来,最后在讨论一下版本号规则。
    题外话跟大家探讨一下version这样的参数怎么传递比较合理。

    首先在APP发版过程中,由于新的版本上有新的功能,有些需要和老的版本做兼容,所以非常有可能服务器端需要知道APP的版本号,
    而服务器在升级服务和自己的API也一定有版本号的概念,虽然很多时候我们可能注意不到,但是版本号这个一定是双方互相都存在的。
    我就是在这样的一个情景下,我们的新的功能要同时需要兼容新的老的APP,所以服务器需要知道所有APP的版本号,这是需要APP传给服务的参数。
    同时服务器也需要在基于某个版本号比如2.8.5做版本号大小的判断。
    比如说小于2.8.5的版本号,那么就是老的逻辑,而大于等于2.8.5的版本就是新的逻辑。这可能是基于版本号的最简单的兼容逻辑了。

    到这里有心的读者一定看出了说为什么加个版本号也会加出问题来了,对这就是加个版本号检查也加出问题的原因。
    我在加检查前,不确定我们的版本号的规则,然后我找统计妹妹仔细统计了近半年的所有的版本号,得到的结果是我们的版本号是x.x.x这样的号码,
    x一定是数字,那这么看来没有问题,我就按这个规则解析比较,结果当遇到上边看到的g1_2.5.5_65这个版本号时,直接numberformatexception.
    还好,我们的处理非常之果断,在版本检查时出里任何异常,都提示用户版本过低,让用户升级。
    但同样暴露出了我们很多的问题,我们的APP经过两年多的发版竟然从来没有统一过版本号,甚至规则都没有统一过。
    再次追问下去,说由于不同的下载渠道和推送渠道,我们会写上不同的版本号,这个答案的结果我当然不满意。
    心中多是无奈也没有办法,于是乎推进版本号赶紧统一,至少在规则上能有一个可以统一解析的规则。
    这里的一个事情做得好的就是至少我们还有版本号,无论当时服务器使用没有使用版本号,至少APP是传了的。
    需要注意的是,版本号这个东西不能随意写,也不能随意规划,这个需要统一规划,而且越快越早规划越好。

    那么这里就引出了第三个问题,版本号的规则问题,关于这个问题,我不想深入探讨和研究。
    百度“软件开发版本号规则”或者“软件开发版本号命名规范”讲的非常之详细,非常明白,很容易理解。
    我想说的无论怎么样一定要指定一个自己可以统一解析的规则和规范,只要按照规则和规范一定能很好的处理版本号。
    我比较推荐的使用的版本号有两种,
    1是:主版本号.次版本号.修订版本号.日期版本号
    2是:主版本号.次版本号.修订版本号.构建版本号
    这样的一组号码,清晰明了,足够用了。

    最后谈一谈版本号怎么传递比较合适,首先我们不说APP,我们做服务器端开发特别是RESTAPI时一定也遇到过说一个API的version问题,
    网上不同的人有不同的见解,不同的网站有不同的实现方式,我说一下我知道的常见的几种方式:
    1、在http header中传递,例如:header.set("version","2.8.5")
    2、在使用url path的方式,例如:/www.xxx.com/order/v2.8.5/create
    3、使用url query paramter的方式传递,例如:/www.xxx.com/order/create?v=2.8.5
    4、使用form表单提交version,(这个貌似极其少见)例如:<form method="post|get" action="/order/create"><hiden name="version" value="2.8.5"/>...</form>
    这个明白了之后那么APP给服务器传参,也无外乎这几种方式,具体使用哪种中方式可以根据自己的喜好而定。
    貌似我在某一篇文章中看到说虽然使用url path的方式比较直观,有些大型的网站也在使用,但是REStful的规范说要在header中使用version才算正统。
    这个就无所谓了,我感觉都行,之前老大还跟我争执过这个,我说要加在url path中就是使用第二种方式,结果老大不同意,说你这样将来要维护一堆的url,v1,v2会很麻烦。
    说推荐第一种,我比较固执的按第二种方式做了,后来另一个同事也讨论起这事,所就按第二种方式比较好,这里老大的态度变了,说啥啥啥公司都是第二种,咱们也第二种吧,
    我心里那个委屈,特么,我早跟你说,你跟我还争个毛线,我做都做了,还在我伤口上撒盐。我跟老大争这些是不是将来做不了老大,悲催。
    现在想想第三种也非常棒,真的也非常不错的。

    好了今天,关于版本号讨论就说这么些吧。


    欢迎大家评论发表意见或提出问题

  • 相关阅读:
    SAP S/4HANA extensibility扩展原理介绍
    SAP CRM系统订单模型的设计与实现
    使用nodejs代码在SAP C4C里创建Individual customer
    SAP Cloud for Customer Account和individual customer的区别
    Let the Balloon Rise map一个数组
    How Many Tables 简单并查集
    Heap Operations 优先队列
    Arpa’s obvious problem and Mehrdad’s terrible solution 思维
    Passing the Message 单调栈两次
    The Suspects 并查集
  • 原文地址:https://www.cnblogs.com/icenter/p/7113648.html
Copyright © 2011-2022 走看看