PyCalVer：自动日历版本控制

弃用警告：此软件包不再维护。它已被BumpVer取代。

PyCalVer是一个cli工具，用于搜索和替换项目中文件中的版本字符串。

默认情况下，PyCalVer使用类似于这样的格式：v201812.0123-beta，但它可以配置为生成多种格式的版本字符串，包括SemVer和其他CalVer变体。

项目/仓库

代码质量/CI

• 用法
  • 配置
  • 模式搜索和替换
  • 示例
  • 版本状态
  • 当前版本
  • 升级它
• PyCalVer格式
  • 解析
  • 增量行为
  • 词法标识符
• PyCalVer的语义
  • 有意破坏性更改
  • 成本和收益
  • 意外破坏性更改
  • 固定并非万无一失
  • Zen的1.0和永恒的Beta

用法

配置

设置项目的最快方法是使用pycalver init。

$ pip install pycalver
...
Installing collected packages: click pathlib2 typing toml six pycalver
Successfully installed pycalver-202010.1043

$ pycalver --version
pycalver, version v202010.1043

$ cd myproject
~/myproject$ pycalver init --dry
WARNING - File not found: pycalver.toml
Exiting because of '--dry'. Would have written to pycalver.toml:

    [pycalver]
    current_version = "v201902.0001-alpha"
    version_pattern = "{pycalver}"
    commit = true
    tag = true
    push = true

    [pycalver.file_patterns]
    "README.md" = [
        "{version}",
        "{pep440_version}",
    ]
    "pycalver.toml" = [
        'current_version = "{version}"',
    ]

如果您已经有一个setup.cfg文件，则init子命令将写入该文件。

~/myproject$ ls
README.md  setup.cfg  setup.py

~/myproject$ pycalver init
WARNING - Couldn't parse setup.cfg: Missing [pycalver] section.
Updated setup.cfg

这将在您的 setup.cfg 文件中添加类似以下的内容（取决于项目中已存在的文件）

# setup.cfg
[pycalver]
current_version = "v201902.0001-alpha"
version_pattern = "{pycalver}"
commit = True
tag = True
push = True

[pycalver:file_patterns]
setup.cfg =
    current_version = {version}
setup.py =
    "{version}",
    "{pep440_version}",
README.md =
    {version}
    {pep440_version}

这或许不能涵盖您项目中使用的所有版本号，您可能需要手动添加到 pycalver:file_patterns 的条目。以下内容可能展示了您可能需要进行的额外更改。

[pycalver:file_patterns]
setup.cfg =
    current_version = {pycalver}
setup.py =
    version="{pep440_pycalver}"
src/mymodule_v*/__init__.py =
    __version__ = "{pycalver}"
README.md =
    [PyCalVer {calver}{build}{release}]
    img.shields.io/static/v1.svg?label=PyCalVer&message={pycalver}&color=blue

要查看是否找到了模式，您可以使用 pycalver bump --dry，这将不会更改您的项目文件，只会显示它将要进行的更改的差异。

$ pycalver bump --dry --no-fetch
INFO    - Old Version: v201901.0001-beta
INFO    - New Version: v201902.0002-beta
--- README.md
+++ README.md
@@ -11,7 +11,7 @@

 [![Supported Python Versions][pyversions_img]][pyversions_ref]
-[![Version v201901.0001][version_img]][version_ref]
+[![Version v201902.0002][version_img]][version_ref]
 [![PyPI Releases][pypi_img]][pypi_ref]

--- src/mymodule_v1/__init__.py
+++ src/mymodule_v1/__init__.py
@@ -1,1 +1,1 @@
-__version__ = "v201901.0001-beta"
+__version__ = "v201902.0002-beta"

--- src/mymodule_v2/__init__.py
+++ src/mymodule_v2/__init__.py
@@ -1,1 +1,1 @@
-__version__ = "v201901.0001-beta"
+__version__ = "v201902.0002-beta"

--- setup.py
+++ setup.py
@@ -44,7 +44,7 @@
     name="myproject",
-    version="201901.1b0",
+    version="201902.2b0",
     license="MIT",

如果没有找到匹配的模式，bump 将会报告错误。

$ pycalver bump --dry --no-fetch
INFO    - Old Version: v201901.0001-beta
INFO    - New Version: v201902.0002-beta
ERROR   - No match for pattern 'img.shields.io/static/v1.svg?label=PyCalVer&message={pycalver}&color=blue'
ERROR   - Pattern compiles to regex 'img\.shields\.io/static/v1\.svg\?label=PyCalVer&message=(?P<pycalver>v(?P<year>\d{4})(?P<month>(?:0[0-9]|1[0-2]))\.(?P<bid>\d{4,})(?:-(?P
<tag>(?:alpha|beta|dev|rc|post|final)))?)&color=blue'

内部使用的正则表达式也会显示，您可以使用它来调试问题，例如在 regex101.com 上。

模式搜索和替换

配置中的 pycalver:file_patterns 部分用于在您的项目文件中搜索和替换版本字符串。除了有效的占位符之外，所有内容都被视为字面文本。可用的占位符有

请注意以下限制

1. 版本字符串不能跨多行。
2. 占位符生成的字符不能转义。
3. 时区始终是 UTC。

例如，转义不足可能导致徽章 URL 出现问题。您可能希望在 README.md 中放入以下文本（请注意，shields.io 将 beta 前面的两个短横线视为一个字面短横线）

https://img.shields.io/badge/myproject-v201812.0116--beta-blue.svg

虽然您可以使用以下模式，这在一段时间内可以正常工作

README.md =
    /badge/myproject-v{year}{month}.{build_no}--{release_tag}-blue.svg

最终这将会出错，当您进行一个 final 发布时，您的 README.md 中将会出现以下内容

https://img.shields.io/badge/myproject-v201812.0117--final-blue.svg

当您可能想要的是这个（省略了 --final 标签）

https://img.shields.io/badge/myproject-v201812.0117-blue.svg

示例

测试模式的最简单方法是使用 pycalver test 子命令。

$ pycalver test 'v18w01' 'v{yy}w{iso_week}'
New Version: v19w06
PEP440     : v19w06

$ pycalver test 'v18.01' 'v{yy}w{iso_week}'
ERROR   - Invalid version string 'v18.01' for pattern
  'v{yy}w{iso_week}'/'v(?P<yy>\d{2})w(?P<iso_week>(?:[0-4]\d|5[0-3]))'
ERROR   - Invalid version 'v18.01' and/or pattern 'v{yy}w{iso_week}'.

如您所见，每个模式都内部转换为正则表达式。

pycalver test 子命令接受与 pycalver bump 相同的 CLI 标志来更新那些没有自动更新的组件（例如，基于日历的）。

$ pycalver test 'v18.1.1' 'v{yy}.{MINOR}.{PATCH}'
New Version: v19.1.1
PEP440     : 19.1.1

$ pycalver test 'v18.1.1' 'v{yy}.{MINOR}.{PATCH}' --patch
New Version: v19.1.2
PEP440     : 19.1.2

$ pycalver test 'v18.1.2' 'v{yy}.{MINOR}.{PATCH}' --minor
New Version: v19.2.0
PEP440     : 19.2.0

$ pycalver test 'v201811.0051-beta' '{pycalver}'
New Version: v201902.0052-beta
PEP440     : 201902.52b0

$ pycalver test 'v201811.0051-beta' '{pycalver}' --release rc
New Version: v201902.0052-rc
PEP440     : 201902.52rc0

$ pycalver test 'v201811.0051-beta' '{pycalver}' --release final
New Version: v201902.0052
PEP440     : 201902.52

请注意，pypi/setuptools/pip 将版本字符串规范化为在 PEP440 中定义的格式。您可以使用不同的格式，但请注意，这些工具处理版本字符串时将看起来不同。

版本状态

“当前版本”被视为全局状态，需要存储在某处。通常这可能是存储在 VERSION 文件中，或存储在存储库中的其他文件。这可能会导致并行分支有不同的状态。如果“当前版本”仅由本地检查出的文件定义，则不同的提交可能会生成相同的版本。

为了避免这个问题，pycalver 将 VCS 标签视为最新版本的规范/单一源真相，并尽可能以最原子的方式尝试更改此状态。这就是为什么一些 pycalver 命令的操作可能需要一段时间，因为它正在与远程存储库同步以获取最新版本，并尽快推送任何新版本标签。

当前版本

将要增加的当前版本定义如下

• 通常：配置中 version_pattern 匹配的词法最大的 git/mercurial 标签。
• 初始状态：在创建任何标签之前（或者您没有使用受支持的版本控制系统），在 setup.cfg / pyproject.toml / pycalver.toml 中的 pycalver.current_version 的值。

在进行 pycalver bump 操作时，您的本地版本控制系统索引会通过 git fetch --tags/hg pull 进行更新。这降低了某些标签本地未知的风险，并减少了为不同提交生成相同版本字符串的可能性，这会导致版本标签模糊。这可能会发生在多个维护者同时发布或构建系统多次触发且多个构建并发运行的情况下。对于小型项目（只有一个维护者且没有构建系统），这不是问题，您可以使用 -n/--no-fetch 跳过标签更新。

$ time pycalver show --verbose
INFO    - fetching tags from remote (to turn off use: -n / --no-fetch)
INFO    - Working dir version        : v201812.0018
INFO    - Latest version from git tag: v201901.0019-beta
Current Version: v201901.0019-beta
PEP440         : 201901.19b0

real    0m4,254s

$ time pycalver show --verbose --no-fetch
...
real    0m0,840s

升级它

要增加当前版本并发布新版本，您可以使用 pycalver bump 子命令。bump 在 pycalver 配置部分中进行配置。

[pycalver]
current_version = "v201812.0006-beta"
version_pattern = "{pycalver}"
commit = True
tag = True
push = True

此配置适用于创建包含以下内容的提交：

1. 包含版本字符串的更改，
2. 不包含其他更改（与增加版本无关），
3. 带有新版本标签，
4. 在存储库中具有唯一的版本标签。

为了确保提交中只包含版本字符串的更改，您需要在调用 pycalver bump 时确保您的版本控制系统签出是干净的。

bump 执行以下步骤：

0. 检查您的存储库没有任何本地更改。
1. 获取 来自源的最新的全局版本控制系统标签（使用 -n/--no-fetch 禁用）。
2. 生成一个新的版本，该版本从当前版本递增。
3. 更新 file_patterns 中配置的所有文件中的版本字符串。
4. 提交 更新的版本字符串。
5. 标记 新提交。
6. 推送 新提交和标记。

再次，您可以使用 --dry 首先检查更改。

$ pycalver bump --dry
--- setup.cfg
+++ setup.cfg
@@ -65,7 +65,7 @@

 [pycalver]
-current_version = v201812.0005-beta
+current_version = v201812.0006-beta
 commit = True
 tag = True
 push = True
...

如果一切看起来正常，您可以执行 pycalver bump。

$ pycalver bump --verbose
INFO    - fetching tags from remote (to turn off use: -n / --no-fetch)
INFO    - Old Version: v201812.0005-beta
INFO    - New Version: v201812.0006-beta
INFO    - git commit --file /tmp/tmpph_npey9
INFO    - git tag --annotate v201812.0006-beta --message v201812.0006-beta
INFO    - git push origin v201812.0006-beta

PyCalVer格式

PyCalVer 的版本字符串格式有三个部分

    o Year and Month of Release
    |       o Sequential Build Number
    |       |      o Release Tag (optional)
    |       |      |
 ---+---  --+--  --+--
 v201812  .0123  -beta

一些示例

v201711.0001-alpha
v201712.0027-beta
v201801.0031
v201801.0032-post
...
v202207.18133
v202207.18134

这种稍微冗长的格式部分是为了与其他格式区分开来，以便您的包的用户可以一眼看出，您的项目将努力维护一个真正重要的语义：**新的等于更好的**。

为了说服您不要破坏事物的优点，以下是一些 PyCalVer 吸取了灵感的资源

• Rich Hicky 的“Speculation”演讲
• Mahmoud Hashemi 的“Designing a Version”
• calver.org
• Kartik Agaram 的“The cargo cult of versioning”
• bumpversion 项目，PyCalVer 部分基于此。
• Russ Cox 的“ Our Software Dependency Problem”

解析

以下版本字符串可以使用以下正则表达式进行解析

import re

# https://regex101.com/r/fnj60p/10
PYCALVER_PATTERN = r"""
\b
(?P<pycalver>
    (?P<vYYYYMM>
       v                    # "v" version prefix
       (?P<year>\d{4})
       (?P<month>\d{2})
    )
    (?P<build>
        \.                  # "." build nr prefix
        (?P<build_no>\d{4,})
    )
    (?P<release>
        \-                  # "-" release prefix
        (?P<release_tag>alpha|beta|dev|rc|post)
    )?
)(?:\s|$)
"""
PYCALVER_REGEX = re.compile(PYCALVER_PATTERN, flags=re.VERBOSE)

version_str = "v201712.0001-alpha"
version_match = PYCALVER_REGEX.match(version_str)

assert version_match.groupdict() == {
    "pycalver"   : "v201712.0001-alpha",
    "vYYYYMM"    : "v201712",
    "year"       : "2017",
    "month"      : "12",
    "build"      : ".0001",
    "build_no"   : "0001",
    "release"    : "-alpha",
    "release_tag": "alpha",
}

version_str = "v201712.0033"
version_match = PYCALVER_REGEX.match(version_str)

assert version_match.groupdict() == {
    "pycalver"   : "v201712.0033",
    "vYYYYMM"    : "v201712",
    "year"       : "2017",
    "month"      : "12",
    "build"      : ".0033",
    "build_no"   : "0033",
    "release"    : None,
    "release_tag": None,
}

增量行为

要查看版本字符串是如何递增的，我们可以使用 pycalver test。

$ pycalver test v201801.0033-beta
New Version: v201902.0034-beta
PEP440     : 201902.34b0

这是一个简单的例子

• 日历组件更新为当前年份和月份。
• 构建号增加 1。
• 可选的发布标签按原样保留。

您可以使用 --release=<tag> 参数显式更新发布标签。

$ pycalver test v201801.0033-alpha --release=beta
New Version: v201902.0034-beta
PEP440     : 201902.34b0

$ pycalver test v201902.0034-beta --release=final
New Version: v201902.0035
PEP440     : 201902.35

为了保持版本号的词法排序，版本号会填充额外的零（见 词法标识符）。

词法标识符

构建号填充最终可能会耗尽。为了保持词法排序，对于 {build_no} 模式的构建号会以特殊方式递增。以下示例可能会更清楚地说明。

"0001"
"0002"
"0003"
...
"0999"
"11000"
"11001"
...
"19998"
"19999"
"220000"
"220001"

这里发生的情况是，最左边的数字提前增加。每当最左边的数字会发生变化时，标识符的填充就会通过乘以 11 来扩展。

>>> prev_id  = "0999"
>>> num_digits = len(prev_id)
>>> num_digits
4
>>> prev_int = int(prev_id, 10)
>>> prev_int
999
>>> maybe_next_int = prev_int + 1
>>> maybe_next_int
1000
>>> maybe_next_id = f"{maybe_next_int:0{num_digits}}"
>>> maybe_next_id
"1000"
>>> is_padding_ok = prev_id[0] == maybe_next_id[0]
>>> is_padding_ok
False
>>> if is_padding_ok:
...     # normal case
...     next_id = maybe_next_id
... else:
...     # extra padding needed
...     next_int = maybe_next_int * 11
...     next_id  = str(next_int)
>>> next_id
"11000"

这种行为确保以下语义始终得到保留：new_version > old_version。这将是正确的，无论填充扩展如何。为了说明这个问题解决的方案，考虑如果我们没有扩展填充，而是仅仅按数字递增会发生什么。

"0001"
"0002"
"0003"
...
"0999"
"1000"
...
"9999"
"10000"

在这里，我们最终会遇到一个构建号，其词法顺序没有得到保留，因为 "10000" > "9999" == False（因为字符串 "1" 在词法上小于 "9"）。对于足够大的填充，这可能不是一个问题，但最好不用去考虑。

举个例子，为什么词法顺序是一个很好的属性，有很多软件读取git标签，但没有解析版本字符串的逻辑。尽管如此，这些软件可以使用常用的词法顺序正确地排序版本标签。在最基本的层面上，它允许您使用UNIX sort命令，例如解析VCS标签。

$ printf "v0.9.0\nv0.10.0\nv0.11.0\n" | sort
v0.10.0
v0.11.0
v0.9.0

$ printf "v0.9.0\nv0.10.0\nv0.11.0\n" | sort -n
v0.10.0
v0.11.0
v0.9.0

$ printf "0998\n0999\n11000\n11001\n11002\n" | sort
0998
0999
11000
11001
11002

这种排序在JavaScript中也是正确的！

> var versions = ["11002", "11001", "11000", "0999", "0998"];
> versions.sort();
["0998", "0999", "11000", "11001", "11002"]

PyCalVer的语义

免责声明：本节当然只能是期望的。没有任何东西可以阻止软件包维护者发布与这里展示的语义不同的软件包。

PyCalVer比SemVer对软件包维护者提出了更高的要求。向后不兼容性没有编码在版本字符串中，因为 维护者不应该故意引入破坏性更改。这对于软件包的用户来说是个好消息，他们可以少担心更新会导致项目中断。当然，偏执的用户可以继续将版本锁定到已知的良好版本，并且在部署时冻结依赖项仍然是一种良好的做法，但对于开发而言，理想情况下，用户不需要在requirements.txt中的需求中指定任何版本。这样，他们总是能得到最新的错误修复和新功能。

PyCalVer版本字符串独特的一部分原因，是为了让用户能够仅通过查看版本字符串就能识别出，一个软件包承诺（或者至少是抱有希望）不会破坏，对用户来说是安全的，可以更新。这与SemVer版本字符串形成对比，在SemVer版本字符串中，维护者明确表示更新 可能 会破坏他们的程序，并且在更新后可能需要做额外的工作，即使过去没有这样做，软件包维护者预计他们将来可能会进行这样的破坏性更改。

换句话说，如果用户想要更新到软件包的最新版本，责任在于软件包的用户来更新他们的软件。在PyCalVer中，责任在于维护者保持向后兼容性。

理想情况下，用户可以相信维护者的承诺，以下语义始终是真实的

• 较新的版本是兼容的。
• 较新的版本有更少的错误。
• 较新的版本有更多的功能。
• 较新的版本有相同或更好的性能。

然而，世界并不完美。那么用户和维护者如何处理违反这些承诺的更改呢？

有意破坏性更改

命名空间是一个非常好的主意

• 让我们做更多这样的！

• Python之禅

如果您必须对一个软件包进行破坏性更改，而不是增加一个数字，PyCalVer建议的做法是创建一个新的命名空间。换句话说，主版本号成为模块或软件包名称的一部分。通常，您可能需要添加一个数字后缀，例如 mypkg -> mypkg2。

在Python发行版的情况下，您可以包含多个模块软件包，如下所示。

# setup.py
setuptools.setup(
    name="my-package",
    license="MIT",
    packages=["mypkg", "mypkg2"],
    package_dir={"": "src"},
    ...
)

换句话说，您可以同时分发旧版本和新版本，用户可以导入他们需要的任何一个。或者，您可以发布一个新的软件包发行版，带有新的命名空间，但请考虑也将模块重命名。

# setup.py
setuptools.setup(
    name="my-package-v2",
    license="MIT",
    packages=["mypkg2"],
    package_dir={"": "src"},
    ...
)

如果使用import mypkg2就能确定用户正在使用项目的哪个版本，那么用户在使用您的软件包时会更加方便。创建多个模块的另一个好处是，用户可以在同一个环境中导入旧模块和新模块，并使用依赖旧版本的一些包以及依赖新版本的一些包。对于用户来说，缺点是他们可能需要对其代码进行一些最小程度的修改，即使这些破坏性变化没有影响到他们。

- import mypkg
+ import mypkg2

  def usage_code():
-     mypkg.myfun()
+     mypkg2.myfun()

成本和收益

如果您认为这有些过度，因为作为维护者需要做很多工作，那么首先考虑投资一些时间在自己的工具上，这样就可以最小化创建新包所需未来的工作。我已经在我的个人项目上做了这件事[链接](https://gitlab.com/mbarkhau/bootstrapit)，但您可能会发现[其他方法](https://cookiecutter.readthedocs.io)更适合您的需求。

如果您认为这有些过度，因为您不认为对用户施加非常小的负担是件大事，那么考虑一下，您的项目可能间接依赖于成百上千个您从未听说过的库。如果每个维护者每年只引入一次破坏性变化，那么只依赖于十几个库的用户将每个月都要处理打包问题！换句话说：破坏性变化是件大事。一些维护者额外的努力似乎是一个公平的交易，以减少对许多用户的负担，这些用户会很乐意继续使用旧代码，直到他们决定何时升级。

意外破坏性更改

另一种破坏性变化是非故意的，通常称为“错误”或“回归”。首先，意识到任何版本控制系统都无法编码这种事情的发生：因为维护者并不是有意引入错误，他们自然无法更新版本号来反映他们不知道的事情。相反，我们必须在事后处理这些问题。

一个软件包维护者可以做的第一件事是最大限度地减少向用户施加有缺陷软件的机会。在每次非平凡（可能破坏性的）更改之后，创建一个-alpha、-beta或-rc预发布版本是一个好习惯。这些所谓的--pre预发布版本仅打算由少数人下载：那些愿意参与测试的人。在解决完--pre预发布版本中的任何问题后，就可以为更广泛的公众发布一个最终版本。

请注意，pip install <package>（不带任何版本指定符）的默认行为是下载最新的最终版本。它只会下载--pre预发布版本，仅在以下情况下：

1. 没有可用的final版本
2. 显式使用了--pre标志，或者
3. 如果要求指定符显式包含预发布版本的版本号，例如pip install mypkg==v201812.0007-alpha。

如果发布中包含错误（虽然希望不会发生，尽管采取了所有预防措施），那么维护者应发布一个新版本，该版本要么修复错误，要么撤销更改。如果用户之前下载了包含错误的软件包版本，他们只需要执行pip install --upgrade <package>，问题就会得到解决。

也许一个时间表可以更清楚地说明

v201812.0665       # last stable release
v201812.0666-beta  # pre release for testers
v201901.0667       # final release after testing

# bug is discovered which effects v201812.0666-beta and v201901.0667

v201901.0668-beta  # fix is issued for testers
v201901.0669       # fix is issued everybody

# Alternatively, revert before fixing

v201901.0668       # same as v201812.0665
v201901.0669-beta  # reintroduce change from v201812.0666-beta + fix
v201901.0670       # final release after testing

在最糟糕的情况下，发现一个更改破坏了向后兼容性，但这个更改仍然被认为是可取的。在这种情况下，应该发布一个新版本来撤销这个更改。

这允许1.曾经暴露于破坏性变化的用户更新到最新版本并再次获得旧（可工作）代码，以及2.没有暴露于破坏性变化的用户甚至不知道有什么被破坏。

记住，目标是始终让使用您的软件包作为依赖项的用户感到方便。如果出现任何问题，他们应该做的只是pip install --update。如果这不起作用，他们可能需要暂时将版本锁定到已知良好的版本，直到发布修复后的版本。

在立即的火灾被扑灭后，如果这个破坏性的变更值得保留，那么就创建一个新的模块，甚至一个新的包。这个包可能与之前的包有99%的相似度，旧的一个可能最终会被放弃。

mypkg  v201812.0665    # last stable release
mypkg  v201812.0666-rc # pre release for testers
mypkg  v201901.0667    # final release after testing period

# bug is discovered in v201812.0666-beta and v201901.0667

mypkg  v201901.0668    # same as v201812.0665

# new package is created with compatibility breaking code

mypkg2 v201901.0669    # same as v201901.0667
mypkg  v201901.0669    # updated readme, declaring support
                       # level for mypkg, pointing to mypgk2
                       # and documenting how to upgrade.

固定并非万无一失

使用pip freeze冻结依赖项以创建一个包含固定特定版本号的包的文件，这对于获得稳定和可重复的部署非常有用。

固定依赖项的主要问题是它给用户带来了另一个负担，这种负担在实践中只有少数人能承担。绝大多数用户要么1)固定依赖项并更新它们，而不确定是否发生了变化或是否安全更新，要么2)固定依赖项并忘记它们。在第一种情况下，唯一的好处是用户至少可以意识到更新何时发生，这样他们可能将新软件中的新错误与最近更新联系起来。除此之外，对依赖项进行跟踪并在不谨慎的情况下更新，几乎与没有固定一样好。在第二种情况下，无法克服的债务会堆积如山，项目的依赖项实际上被冻结在过去了。

是的，如果用户有足够的测试覆盖率来判断他们的代码在依赖项更新后是否损坏，那么他们就会更好。然而，这也意味着包维护者通常处于更好的位置，可以判断一个更改是否会导致某些内容损坏。

Zen的1.0和永恒的Beta

向后兼容性有两种相反的方法，这在它们使用的版本号中得到了反映。在SemVer的情况下，如果一个项目有向后兼容性的承诺，那么它可能永远不会升级主版本，导致芝诺1.0悖论。另一端是那些避免对向后兼容性做出任何承诺的项目，它们永远保留“beta”标签。

当然，未付费的开源开发者没有义务对向后兼容性做出承诺。特别是当项目处于初期且正在经历重大变化时，这样的承诺可能没有任何意义。对于这些情况，您仍然可以使用PyCalVer，只要在README的顶部有一个大大的警告，说明您的项目还没有准备好投入生产。

请注意，处于“beta”状态的软件和具有-beta标签的个别发布版之间存在差异。这些并不意味着相同的事情。在python包的发布中，发布标签（-alpha、-beta、-rc）说明了特定发布的稳定性。这类似于（可能是相同的）CPython解释器使用的发布标签的含义。发布标签并不是关于软件整体稳定性的声明，而是关于包的特定发布实体的元数据，例如.whl文件。

https://gitlab.com/mbarkhau/pycalver的变更日志

v201907.0036

• 修复：如果配置了commit=False，则不要使用git/hg命令（感谢@valentin87）

v201907.0035

• 修复gitlab#6：添加部分{month_short}、{dom_short}、{doy_short}。
• 修复gitlab#5：在使用bump与semver时提供更好的警告（需要之一--major/--minor/--patch）
• 修复gitlab#4：使{release}部分可选，以便解析由--release=final生成的版本。

v201903.0030

• 修复：使用配置中的模式而不是硬编码的{pycalver}模式。
• 修复：更好地处理git/hg问题时的错误消息。
• 添加：配置文件的隐式默认模式。

v201903.0028

• 修复：当配置文件不在版本控制下时添加警告。
• 新增：bump --dry 的彩色输出。

v201902.0027

• 修复：允许 --release=post。
• 修复：对不良模式的错误报告改进。
• 修复：与 "?" 相关的正则表达式转义问题。

v201902.0024

• 新增：支持在文件模式中使用glob。
• 修复：对无效配置的错误报告改进。

v201902.0020

• 新增：支持更多自定义版本模式。

v201812.0018

• 修复：对 "-final" 版本的模式替换处理改进。

v201812.0017

• 修复：github#2. pycalver init 故障。
• 修复模式转义问题。
• 新增更多cli测试。
• 整理文档。

v201812.0011-beta

• 使用git/hg添加版本标签。
• 使用git/hg标签作为最新版本的SSOT。
• 开始使用 https://gitlab.com/mbarkhau/bootstrapit
• 迁移到 https://gitlab.com/mbarkhau/pycalver

v201809.0001-alpha

• 初始版本