您的位置:新葡亰496net > 电脑系统 > 新葡亰496net:本子号格式,版本格式

新葡亰496net:本子号格式,版本格式

发布时间:2019-07-14 22:06编辑:电脑系统浏览(150)

    版本号表示格式为 epoch:version-release,例如 1:2-3

    题目:比较两个版本号version1和version2。
    如果版本 1 > 版本2返回1,则版本 1 < 版本2返回-1,否则返回0。
    您可能认为版本字符串不是空的,只包含数字和.字符。
    该.字符不代表小数点,用于分隔数字序列。
    例如,2.5不是“二分之二”或“三分之一”,是第二次一级修订的第五次修订。
    以下是版本号排序的示例:
    0.1 <1.1 <1.2 <13.37

    版本格式:主版本号.次版本号.修订号

    本文章翻译自 https://semver.org/
    中文版在这里 https://semver.org/lang/zh-CN/,但读起来太困难。这里搞一版更教程化, 但又不失严谨的。

    定义了公共API,你就可以透过修改相应的版本号来向大家说明你的修改。考虑使用这样的版本号格式:XYZ (主版本号.次版本号.修订号)修复问题但不影响API 时,递增修订号;API 保持向下兼容的新增及修改时,递增次版本号;进行不向下兼容的修改时,递增主版本号。

    第一条原则是 rpm 属性优先级 epoch > version > release
            两个 rpm 包比较时,先看两者的 epoch 哪个新,如果 epoch 相等,再看 version 哪个新,如果 version 还相等,最后看 release 哪个新,要是 release 也相等,那么这两个 rpm 包的版本是相等的。
    0:1-2 > 0:1-1
    0:2-1 > 0:1-3
    1:1-1 > 0:2-2

    思路:分别对版本号以.分割,按最大长度对版本号数组循环,按顺序比较。

    版本号递增规则如下:

    一个良好的版本号的结构与改动规则,向用户传达了我们软件中改动的影响级别。
    作者在这篇官方文档里,给出了对 semver 的精准定义。

    以下关键词MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、 RECOMMENDED、MAY、OPTIONAL 依照RFC 2119 的叙述解读。(译注:为了保持语句顺畅, 以下文件遇到的关键词将依照整句语义进行翻译,在此先不进行个别翻译。)

    第二条原则是版本号字段列表分隔模式
            epoch 属性之外,version 和 release 可能不单单包含数字,也可能含有字符串,例如 1.0alpha1、2.0.0 svn12221
            遇到这种情况时,版本号字段会被分隔为列表。分隔策略是数字与字符串分开,形成自然分隔边界,点号/加号/减号/下划线作为分隔符。1.0alpha1 会分为 [ 1、0、alpha、1 ],2.0.0 svn12221 会分为 [ 2、0、0、svn、12221 ]。这样子分隔的目的是为了列表相应分段进行比较,比较的优先级按照列表的下标顺序自然排序,第一位的优先级最高,后面依次降低。如果两个列表可比较的分段经过比较后都相等,那么列表长的比列表短的新,如果列表长度也一样,那么这两个版本号字段相等。
    1.2.0 > 1.1.9            ( [1,2,0] 中第2分段的“2” > [1,1,9] 中第2分段的“1” )
    1.12.1 > 1.9beta2   ( [1,12,1] 中第2分段的“12” > [1,9,beta,2] 中第2分段的“9” )
    3.1.0 > 3.1               ( [3,1,0] 的列表长度3 > [3,1] 的列表长度2 )

    代码:

    • 主版本号:当你做了不兼容的API 修改。
    • 次版本号:当你做了向下兼容的功能性新增。
    • 修订号:当你做了向下兼容的问题修正。

    搬运正文

    1. 使用语义化版本控制的软件“必须MUST”定义公共API。该API可以在代码中被定义或出现于严谨的文件内。无论何种形式都应该力求精确且完整。
    2. 标准的版本号“必须MUST”采用XYZ的格式,​​ 其中X、Y和Z为非负的整数,且“禁止MUST NOT”在数字前方补零。X是主版本号、Y是次版本号、而Z为修订号。每个元素“必须MUST”以数值来递增。例如:1.9.1 -> 1.10.0 -> 1.11.0。
    3. 标记版本号的软件发行后,“禁止MUST NOT”改变该版本软件的内容。任何修改都“必须MUST”以新版本发行。
    4. 主版本号为零(0.yz)的软件处于开发初始阶段,一切都可能随时被改变。这样的公共API 不应该被视为稳定版。
    5. 1.0.0 的版本号用于界定公共API 的形成。这一版本之后所有的版本号更新都基于公共API 及其修改内容。
    6. 修订号Z(xyZ | x > 0)“必须MUST”在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改。
    7. 次版本号Y(xYz | x > 0)“必须MUST”在有向下兼容的新功能出现时递增。在任何公共API的功能被标记为弃用时也“必须MUST”递增。也“可以MAY”在内部程序有大量新功能或改进被加入时递增,其中“可以MAY”包括修订级别的改变。每当次版本号递增时,修订号“必须MUST”归零。
    8. 主版本号X(Xyz | X > 0)“必须MUST”在有任何不兼容的修改被加入公共API时递增。其中“可以MAY”包括次版本号及修订级别的改变。每当主版本号递增时,次版本号和修订号“必须MUST”归零。
    9. 先行版本号“可以MAY”被标注在修订版之后,先加上一个连接号再加上一连串以句点分隔的标识符号来修饰。标识符号“必须MUST”由ASCII码的英数字和连接号[0-9A-Za-z-]组成,且“禁止MUST NOT”留白。数字型的标识符号“禁止MUST NOT”在前方补零。先行版的优先级低于相关联的标准版本。被标上先行版本号则表示这个版本并非稳定而且可能无法达到兼容的需求。范例:1.0​​.0-alpha、1.0.0-alpha.1、 1.0.0-0.3.7、1.0.0-x.7.z.92。
    10. 版本编译信息“可以MAY”被标注在修订版或先行版本号之后,先加上一个加号再加上一连串以句点分隔的标识符号来修饰。标识符号“必须MUST”由ASCII的英数字和连接号[0-9A-Za-z-]组成,且“禁止MUST NOT”留白。当判断版本的优先层级时,版本编译信息“可SHOULD”被忽略。因此当两个版本只有在版本编译信息有差别时,属于相同的优先层级。范例:1.0.0-alpha 001、1.0.0 20130313144700、 1.0.0-beta exp.sha.5114f85。
    11. 版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时,“必须MUST”把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较(版本编译信息不在这份比较的列表中)。由左到右依序比较每个标识符号,第一个差异值用来决定优先层级:主版本号、次版本号及修订号以数值比较,例如1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。当主版本号、次版本号及修订号都相同时,改以优先层级比较低的先行版本号决定。例如:1.0.0-alpha < 1.0.0。有相同主版本号、次版本号及修订号的两个先行版本号,其优先层级“必须MUST”透过由左到右的每个被句点分隔的标识符号来比较,直到找到一个差异值后决定:只有数字的标识符号以数值高低比较,有字母或连接号时则逐字以ASCII的排序来比较。数字的标识符号比非数字的标识符号优先层级低。若开头的标识符号都相同时,栏 ​​位比较多的先行版本号优先层级比较高。范例:1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0- rc.1 < 1.0.0。

    第三条原则是列表分段比较算法
    新葡亰496net,        具体的算法应用于两个待比较的分段串,由于第二条原则的关系,这里的串只可能都是数字或都是字母,例如 "12"、"abc"、"BETA"
            如果是数和数比较,那么两个串会看作两个整数进行自然数比较,前导的零会被忽略,"12" -> 12,"00010" -> 10。
            如果是字符串和字符串比较,那么会进行如同 C 语言 strcmp() 函数的逻辑,按照 ACSII 码顺序得出,排在后面的为新版本,小写字母比大写字母新。
            如果是字符串和数比较,那么认定数比字符串新。
    123 > 121
    svn > rc
    alpha > Beta
    0 > beta

    public int compareVersion(String version1, String version2) {
        String[] levels1 = version1.split("\\.");
        String[] levels2 = version2.split("\\.");
    
        int length = Math.max(levels1.length, levels2.length);
        for (int i=0; i<length; i  ) {
            Integer v1 = i < levels1.length ? Integer.parseInt(levels1[i]) : 0;
            Integer v2 = i < levels2.length ? Integer.parseInt(levels2[i]) : 0;
            int compare = v1.compareTo(v2);
            if (compare != 0) {
                return compare;
            }
        }
    
        return 0;
    }
    

    先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。

    概述

    给定一个版本号: MAJOR.MINOR.PATCH (主版本号.次版本号.补丁版本号):

    1. 当你修改了 API,使其(与之前版本)不兼容时,递增 MAJOR,
    2. 当你用向后兼容的方式加了些功能时,递增 MINOR,
    3. 当你用向后兼容的方式解决了几个 Bug 时,递增 PATCH

    预发布版本 附加的标签,以及与编译相关的额外信息,可以作为 MAJOR.MINOR.PATCH 这种格式的扩展,加到版本号的后面。

    摘自:
    https://leohxj.gitbooks.io/a-programmer-prepares/content/programmer-basic/semantic-versioning.html

            最后给出一些例子,应该足够说明 rpm 包的版本号比较是如何的了。新葡亰496net 1
    1.00010 > 1.9,因为 10 > 9
    2.02 = 2.2,因为 02 = 2
    3.4.0 > 3.4,因为 3.4.0 多出一个列表分段
    5mgc25 = 5.mgc.25,因为分隔后的列表两者相等
    6.0 > 6beta,因为数字比字符串新

    复杂度
    时间 O(N) 空间 O(N)


    引言

    在软件管理的世界里, 有个可怕的地方, 叫 "Dependency Hell"[[1]](https://www.jianshu.com/p/e2619a7aa60e#fn1). 你的系统规模增长的越大, 集成到系统里的软件包越多, 你就越有可能发现, 某天, 你已经深深的陷入了这种绝望之地.

    在那些有很多依赖包的系统里, 发布新的软件包版本很快就会变成一个梦靥. 如果依赖要求太紧, 你可能会陷入 "版本锁定" [[2]](https://www.jianshu.com/p/e2619a7aa60e#fn2). 如果版本要求太松, 你又不可避免的遭受"版本滥交"[[3]](https://www.jianshu.com/p/e2619a7aa60e#fn3)之痛. [[4]](https://www.jianshu.com/p/e2619a7aa60e#fn4). 而所谓的 "Dependency Hell", 就是当 "版本锁定" 和/或 "版本滥交" 阻止你简单, 安全的推动项目前行的时候, 你的处境.

    作为这个问题的一个解决方案, 我提议一套简单的规则和要求, 以规定如何分配和增长版本号. 这些规定基于, 但不限于已经在各种闭源, 开源软件中广泛使用的普遍惯例. 要想这套理论奏效, 首先你得声明一个公开的 API. API 可能是由文档组成的, 也可能是直接使用代码实现的. 但不管怎样, 重要的是这个 API 是清晰和精确的. 一旦你确定了你的 API, 使用增加特定的版本号的方式, 来传达 API 的改动. 考虑一个 X.Y.Z (新葡亰496net:本子号格式,版本格式。MAJOR.MINOR.PATCH) 的版本号格式: 那么, 不影响 API 的Bug修复: 递增补丁版本号Z; 向后兼容的 API 的添加或修改: 递增次版本号; 不向后兼容的 API 的修改: 递增主版本号.

    这套理论我称作 "Semantic Versioning", 那些个版本号以及他们的改变传达着与 底层代码, 以及从一个版本到另一个版本改了什么 相关的含义.

    1. 使用语义化版本控制的软件“必须MUST”定义公共API。该API可以在代码中被定义或出现
      于严谨的文件内。无论何种形式都应该力求精确且完整。
    2. 标准的版本号“必须MUST”采用XYZ的格式, 其中X、Y和Z为非负的整数,且“禁止MUST
      NOT”在数字前方补零。X是主版本号、Y是次版本号、而Z为修订号。每个元素“必须
      MUST”以数值来递增。例如:1.9.1 -> 1.10.0 -> 1.11.0。
    3. 标记版本号的软件发行后,“禁止MUST NOT”改变该版本软件的内容。任何修改都“必须
      MUST”以新版本发行。
    4. 主版本号为零(0.yz)的软件处于开发初始阶段,一切都可能随时被改变。这样的公共
      API 不应该被视为稳定版。
    5. 1.0.0 的版本号用于界定公共API 的形成。这一版本之后所有的版本号更新都基于公共
      新葡亰496net:本子号格式,版本格式。API 及其修改内容。
    6. 修订号Z(xyZ | x > 0)“必须MUST”在只做了向下兼容的修正时才递增。这里的修正指的
      是针对不正确结果而进行的内部修改。
    7. 次版本号Y(xYz | x > 0)“必须MUST”在有向下兼容的新功能出现时递增。在任何公共
      API的功能被标记为弃用时也“必须MUST”递增。也“可以MAY”在内部程序有大量新功能或
      改进被加入时递增,其中“可以MAY”包括修订级别的改变。每当次版本号递增时,修订
      号“必须MUST”归零。
    8. 主版本号X(Xyz | X > 0)“必须MUST”在有任何不兼容的修改被加入公共API时递增。其
      中“可以MAY”包括次版本号及修订级别的改变。每当主版本号递增时,次版本号和修订
      号“必须MUST”归零。
    9. 先行版本号“可以MAY”被标注在修订版之后,先加上一个连接号再加上一连串以句点分隔
      的标识符号来修饰。标识符号“必须MUST”由ASCII码的英数字和连接号[0-9A-Za-z-]组
      成,且“禁止MUST NOT”留白。数字型的标识符号“禁止MUST NOT”在前方补零。先行版
      的优先级低于相关联的标准版本。被标上先行版本号则表示这个版本并非稳定而且可能
      无法达到兼容的需求。范例:1.0.0-alpha、1.0.0-alpha.1、 1.0.0-0.3.7、1.0.0-
      x.7.z.92。
    10. 版本编译信息“可以MAY”被标注在修订版或先行版本号之后,先加上一个加号再加上一连
      串以句点分隔的标识符号来修饰。标识符号“必须MUST”由ASCII的英数字和连接号[0-9AZa-z-]组成,且“禁止MUST
      NOT”留白。当判断版本的优先层级时,版本编译信息“可
      SHOULD”被忽略。因此当两个版本只有在版本编译信息有差别时,属于相同的优先层
      级。范例:1.0.0-alpha 001、1.0.0 20130313144700、 1.0.0-beta exp.sha.5114f85。
    11. 版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时,“必须MUST”把版
      本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较(版本编译信息不
      在这份比较的列表中)。由左到右依序比较每个标识符号,第一个差异值用来决定优先
      层级:主版本号、次版本号及修订号以数值比较,例如1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。当
      主版本号、次版本号及修订号都相同时,改以优先层级比较低的先行版本号决定。例
      程序员的自我修养
      语义化版本 12
      如:1.0.0-alpha < 1.0.0。有相同主版本号、次版本号及修订号的两个先行版本号,其优
      先层级“必须MUST”透过由左到右的每个被句点分隔的标识符号来比较,直到找到一个差
      异值后决定:只有数字的标识符号以数值高低比较,有字母或连接号时则逐字以ASCII的
      排序来比较。数字的标识符号比非数字的标识符号优先层级低。若开头的标识符号都相
      同时,栏 位比较多的先行版本号优先层级比较高。范例:1.0.0-alpha < 1.0.0-alpha.1 <
      1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0- rc.1 < 1.0.0。@

    Semantic Versioning 规范

    1. 使用 Semantic Versioning 的软件 必须 声明一个公共的 API. 这个 API 可能是定义在代码里的, 或者仅仅存在于文档里, 不论用什么方式实现, 它都必须精确而全面.

    2. 一个正常的版本号必须使用 X.Y.Z 的格式, 其中 X, Y, 和 Z 都是非负的整数, 并且 必须不能 包含前导零.
      X 是主版本号, Y 是次版本号, 而 Z 是补丁版本号. 每个元素都必须以数字的方式递增. 举例: 1.9.0 -> 1.10.0 -> 1.11.0.

    3. 一旦一个打了版本的包被发布出去了, 那个版本的内容就 不能 再修改了. 任何修改 必须 作为一个新的版本重新发布.

    4. 主版本为零 (0.y.z) 的版本, 是用作初始开发阶段的. 任何东西都可能在任意的时间被更改. 这时候我们不应该认为它的 API 是稳定的.

    5. 1.0.0 版本表明对外公开 API 的形成. 从此之后, 版本号的递增方式取决于这个公开的API, 以及它如何修订.

    6. 补丁版本号Z (x.y.Z | x > 0) . 如果只有向后兼容的bug修复被引入的化, 补丁版本号 Z 必须 递增. "Bug修复"是指一个修正错误行为的内部修改.

    7. 次版本号Y (x.Y.z | x > 0). 如果一个新的, 向后兼容的功能被引入到了公开 API 里, 次版本号 必须 递增. 如果公开 API 的任何功能被标记为 "已弃用的", 次版本号 必须 递增. 如果大量的新功能或改进被引入到私有代码里的时候, 次版本号 可以 递增. 次版本号的改变 可以 包含补丁级别的改动. 当递增了次版本号的时候, 补丁版本号 必须 清零.

    8. 主版本号X (X.y.z | X > 0). 如果任何的向后不兼容的改动被引入到了公开 API中, 主版本号 必须 递增. 它的递增 可以 包含次版本和补丁级的改动. 当主版本号递增时, 次版本号和补丁版本号 必须 清零.

    9. 一个预发布版本 可以 通过在补丁版本号后面追加一个短线, 以及一系列的用点分割的标识符 来描述. 标识符 必须 仅包含 ASCII 的 阿拉伯数字和短线 [0-9A-Za-z-]. 标识符 必须不 为空. 数字标识符 不能 包含前导零. 预发布版本比对应的正常版本的优先级要低. 预发布版本表明, 它不稳定, 并且可能不满足其对应的正常版本所预定的兼容性要求. 例子: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

    10. 编译时的附加信息, 可以 通过在补丁版本号后面追加一个加号, 以及一系列的用点分割的标识符 来描述. 标识符 必须 仅包含 ASCII 的 阿拉伯数字和短线 [0-9A-Za-z-]. 标识符 必须不 为空. 在比较版本优先级的时候, 编译附加信息 应该 被忽略. 因此, 两个只有编译附加信息不同的版本, 具有相同的优先级. 编译附加信息的举例: 1.0.0-alpha 001, 1.0.0 20130313144700, 1.0.0-beta exp.sha.5114f85.

    11. 优先级是指在排序的时候怎样比较不同的版本. 计算优先级的时候, 必须 将版本号以 "主版本号", "次版本号", "补丁版本号", "预发布标识符" 的顺序拆分. 优先级取决于, 在从左至右依次比较这些个标识符的时候, 发现的第一个差别. "主版本号", "次版本号", "补丁版本号" 总是以数字的方式参加比较. 举例: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1.
      当"主版本号", "次版本号", "补丁版本号" 都相同的时候, 预发布版本比正常的版本优先级要低. 举例: 1.0.0-alpha < 1.0.0.
      如果两个预发布版本有相同的 "主版本号", "次版本号", "补丁版本号", 优先级就 必须 通过比较点分割的标识符来确定, 从左至右依次比较, 直到发现一个不同: 只有数字的标识符号以数值高低比较, 有字母或连接号时则逐字以 ASCII 的排序来比较. 数字的标识符号比非数字的标识符号优先级低. 若开头的标识符号都相同时, 字段比较多的预发布版本号优先层级高. 举例: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.


    为什么使用 Semantic Versioning ?

    (我的这套理论) 并不是什么新的或者革命性的点子,实际上,很可能你已经做了些很接近这个的工作。但问题在于,仅仅是“接近”并不够。如果不遵守有点儿"官方"的协定,版本号对于管理依赖来说基本没什么用。通过给我上面的思想命名,并给予其清晰的定义,将你的意图传达给你的软件的用户就变得很简单了。一旦意图清晰明了,最终一个灵活的(但也不是过于灵活的)软件依赖要求就可以搞定了。
    我们可以通过一个简单的例子,展示一下 Semantic Versioning 可以让 “Dependency Hell” 成为历史。考虑一个叫做 “消防车” 的版本库,他需要一个使用了 Semantically Version 的软件包 “梯子”。当 “消防车” 刚创建的时候,“梯子”在3.1.0 版本。因为“消防车”使用了 “梯子” 3.1.0 新引入的功能,你可以简单的指定,你的“消防车” 对“梯子”的依赖要求是:大于等于 3.1.0 ,但小于 4.0.0 。现在,梯子 "3.1.1" 和 "3.2.0" 好了,你可以把他们发布到你的软件包管理系统,并且你知道他们跟现有的、跟它有依赖关系的包是兼容的。
    作为一个负责人的开发者,你当然想验证任何软件包升级都是正常的、跟你宣传的一样。但现实世界是一团乱麻,对此我们除了小心再小心之外没有更好的办法。你能做的,是让 “Semantic Versioning” 提供你一个合理的方法去发布、升级软件包,而不必去搞许多新版的依赖包,节省了你的时间,免去了许多麻烦。
    如果所有这些听起来挺给力的,要开始使用 “Semantic Versioning” 的话,你只需要声明你正在这么搞,然后遵守这些规范就好了。把这个网站链接到你的 README 文档里,以便其他其他人也可以了解这些规则,并从中受益。

    忘了附带链接了,有空加

    FAQ

    • 在初始开发阶段,怎么去处理 0.y.z 的版本号?
      一个简单的做法是, 使用 0.1.0 作为第一版初始开发版本号,然后为随后的发布包递增次版本号(minor version)
    • 我怎么知道什么时候发布 1.0.0 版?
      如果你的软件已经在生产环境了(已经上线了), 很可能已经 1.0.0 了。如果你做好了一个 从此用户可以信赖的、稳定的API版本,你应该发布1.0.0。如果你正为向后兼容的事情心烦,你应该早就 1.0.0 了。
    • 这东西难道不会阻挠快速开发、快速迭代吗?
      为零的主版本就是为了快速开发的。如果你每天都在改 API,你要么还在 0.y.z,要么在另外一个开发分支上,为下一个主版本做准备。
    • 如果,哪怕是微小的 API 的不兼容改动,主版本都要蹦,我岂不是很快就到 42.0.0 版了?
      这是个关于为开发负责,以及前瞻性的问题。在有许多代码依赖之的软件中,不应该轻率的做不兼容的改动。升级招致的代价可能是相当大的。不得不通过递增主版本号来发行不兼容的改版,意味着你将充分考虑改动所带来的影响,并且评估所涉及的 成本/收益 比。
    • 整理个 API 的文档太费事儿了!
      为供他人使用的软件编写适当的文件,是你作为一名专业的开发者应尽的职责。“管理项目复杂度” 是保持项目高效的非常重要的一部分,而如果没有人知道如何使用你的软件,或者不知道哪些函数可以放心的调用的话,就不好做。Semantic Versioning,以及对 良好定义的API 的坚持,可以让每个人、每件事情都顺利进行。
    • 要是我不小心把一个不向后兼容的改动当成一个次版本号发布了怎么办?
      一旦发现你破坏了 Semantic Versioning 规范,马上解决这个问题,然后发布一个新的次版本,以恢复向后兼容。即使在这种情况下,直接修改已经发行的版本也是不可接受的。如合适,在文档里写明这个有问题的版本,并将这个问题告知你的用户,以便用户知晓这个出问题的版本。
    • 如果我在没有更新API的前提下,更新了我自己(软件)的依赖,应该怎么做?
      由于没有影响到公共 API,这将被当做是兼容的。那些使用了跟你一样的依赖包的软件,应该也有自己的依赖要求,并且如果有冲突的话,他们的作者会注意到的。要判定改动是属于补丁级别还是次版级别,要看你更新依赖包是为了修复Bug,还是添加新功能。对于后者,我通常觉着会有额外的代码,这种情况下,显然是一个次版本号级别的递增。
    • 如果我变更了公共 API 但无意中未遵循版本号的改动怎么办呢?(意即在补丁级的发布中,误将重大且不兼容的改变加到了代码之中)
      自行做最佳的判断。如果改回 API 预期的行为将强烈的影响你的大量受众,那么可能最好再发一个主版本吧,即使这个修复仅仅被当做一个补丁版本。记住,Semantic Versioning 所做的就是,通过版本号的改动传达含义。若这些改变对你的使用者很重要,那就通过版本号来告知他们。
    • 我该如何处理即将弃用的功能?
      弃用现存的功能,是软件开发中正常的一部分,也通常是向前发展所必须的。当你弃用部份 API 时,你应该做两件事:(1)更新你的文档让使用者知道这个改变(2)发布一个新的、仍然包含这些已经弃用的API 的次版本。在你从新的主版本里完全移除这些已弃用的功能之前,至少要有一个次版本 仍然包含这些已经弃用的 API,这样使用者才能平滑地转移到新版 API。
    • Semantic Versioning 对于版本的字串长度是否有限制呢?
      没有,但自行判断。举例来说,一个包含255个字符的版本字符串很可能太过分了。并且,特定的系统对于字串长度可能会有他们自己的限制。

    1. "依赖地狱". 因为不好翻译, 就不译了. ↩

    2. "version lock" (如果不为每一个依赖包都发布一个新版本, 就没办法升级某个软件包). ↩

    3. "version promiscuity" (承担了与太多未来版本兼容的责任, 远远超过合理的需要). ↩

    4. 依赖过紧举例: 假设软件 A 依赖软件 B, 声明 A 的当前版需要 B 的 v1.1 版本, A 的下一个版本需要 B 的 v1.2 版本. 这就过紧了. 这样如果要将A升级到下一个版本, 你就不得不同时发布 B 的 v1.2 版本; 依赖过松举例: 声明 A的当前版本需要B, 只要 B 的版本大于 v1.1 即可. 这样子A 负担过重了, 处理与太多的B的未来版本的兼容问题, 没什么必要. ↩

    本文由新葡亰496net发布于电脑系统,转载请注明出处:新葡亰496net:本子号格式,版本格式

    关键词: