版本规范
========

语义化版本SemVer
----------------

* https://semver.org/lang/zh-CN/

::

    版本格式:
        主版本号.次版本号.修订号[- 先行版本号][+ 版本编译元数据]
    版本号递增规则如下:
    1. 主版本号: 当你做了不兼容的 API 修改
    2. 次版本号: 当你做了向下兼容的功能性新增
    3. 修订号: 当你做了向下兼容的问题修正
    4. 先行版本号及版本编译元数据: 可以加到“主版本号.次版本号.修订号”的后面，作为延伸


实例::

    完整版本=1.2.3-alpha.1

    SHORT=1.2.3

    MAJOR=1
    MINOR=2
    PATCH=3
    PRERELEASE=alpha.1


    1. 1.0.0-alpha+001          => 先行版本: alpha, 版本编译元数据: 001
    2. 1.0.0+20130313144700     => 版本编译元数据: 20130313144700


主版本号为零的时候就是为了做快速开发::

    如果你每天都在改变 API，那么你应该仍在主版本号为零的阶段（0.y.z），或是正在下个主版本的独立开发分支中
    The v0.x.y tags indicate that go APIs may change in incompatible ways in different versions.


万一不小心把一个不兼容的改版当成了次版本号发行了该怎么办？::

    一旦发现自己破坏了语义化版本控制的规范，就要修正这个问题，并发行一个新的次版本号来更正这个问题并且恢复向下兼容
    即使是这种情况，也不能去修改已发行的版本
    可以的话，将有问题的版本号记录到文件中，告诉使用者问题所在，让他们能够意识到这是有问题的版本