我添加了 0.9.14.304 这不是一个稳定的版本，但这是我目前使用的…
也许我们也可以找到一些旧的 0.9.14 版本来标记。直到 0.9.15 准备就绪……如果你知道一些很好用的提交 ID，我可以标记它。

顺便说一句，您是否考虑过基于 pypi 版本构建软件包？https://pypi.org/project/bCNC/

您要打包什么发行版？

@greyltc您如何看待基于 pip 发布的软件包？这对你来说是好的解决方案吗？

对不起，我错过了你之前的评论。我正在为 Arch 打包。

出于多种原因，当我打包东西时，我会努力从尽可能接近作者的地方获取我构建的源 tarball。如果标签在这个 repo 中而不是在 pypi.org 上的某个地方，那就太好了，因为这是我计划从中获取源代码的地方。

我正在为 Arch 打包。

很高兴听到。我几乎只使用 Arch，尤其是在 bCNC 开发期间。我想我们可以想出办法。

顺便说一句，可以在 PKGBUILD 中使用 pip/pypi 来获取包：
https ://wiki.archlinux.org/index.php/Python_package_guidelines#pip
https://wiki.archlinux.org/index.php/Python_package_guidelines#Source

另外我认为添加某种称为“稳定”的滚动标签应该很容易，它总是指向上传到 pypi 的最新提交。然而最近我们设法让 git master 或多或少保持稳定……

我更喜欢从这里获取源代码的原因是这样我可以确定我得到的源代码压缩包的内容与人们在这里审查的内容相匹配。

你认为有什么方法可以让我们从托管在 github.com 上的 repo 的源 tarball 快照构建项目吗？如果您愿意，我很乐意将您添加为 AUR 包的共同维护者！https://aur.archlinux.org/packages/bcnc/

我目前使用这两个文件来发布：

https://github.com/vlachoudis/bCNC/blob/master/setup.py
https://github.com/vlachoudis/bCNC/blob/master/makefile

每当我觉得 bCNC 中有足够的变化对人们有用并且 bCNC 相当稳定时，我只需增加版本号setup.py并提交它（通常消息是“pypi bump”或其他东西）。然后我调用make uploadwhich automaticaly uploads current commit to pypi.

知道了。除了确保稳定的 Arch 包与您当时修改版本号的提交匹配之外，我会尝试说setup.py。

我已经修改了 makefile，所以每次我上传时它都会用名为“pypi”的标签标记上传到 pypi 的最新提交。
所以你也许可以使用它。

这种方法适合您的用例吗？

是的，那应该有效。谢谢！

您好，我想为 Debian 打包 bCNC。我们通常使用标签页面来uscan检测更新的版本。但是，此处列出的最新版本是 0.9.14.304。是否可以使用适当的标签而不是使用“pypi”标签来标记每个新版本？因为有了这个“pypi”标签，我们无法检测到新版本何时发布，以及版本号是多少。

每次更改版本时，您都需要推送一个新标签setup.py。你觉得这合理吗？

有可能的。但是我有点担心会有太多的标签，它会在 github 上变得混乱……

另一方面……我们启用了 Travis CI。
理想情况下，我想使用 Travis 为每个标签（甚至提交）自动为所有平台生成和上传包。
如果您可以提供自定义 Travis 脚本，我可以将它们添加到我们的管道中。

有可能的。但是我有点担心会有太多的标签，它会在 github 上变得混乱……

有很多版本是可以的。例如，参见svgelements。

理想情况下，我想使用 Travis 为每个标签（甚至提交）自动为所有平台生成和上传包。
如果您可以提供自定义 Travis 脚本，我可以将它们添加到我们的管道中。

Debian 的工作方式是应该手动导入包，而不是自动从上游导入。但是，如果您正在推送标签，这很容易使用 3 个命令来更新到 Debian 的最新版本。我目前正在将我的补丁作为拉取请求推送到项目，以便上游和 Debian 在未来的版本中非常相似。

不幸的是，预构建的外部二进制文件（就像来自您的 Travis CI 的文件）对于 Arch 包不是很有用。我们的打包系统需要获取并构建源代码。

我也不确定为什么在这个回购协议中有很多标签是一件坏事。老实说，现在的情况似乎更加混乱，pypi.org 中有一堆标签：https ://pypi.org/project/bCNC/#history 与此处的标签不匹配！

顺便说一句，我在使用 pip 安装的 python 包和由发行版特定的包管理器（ArchLinux 上的 pacman）安装的包之间存在奇怪的冲突。我有点讨厌每个人都在推动他们的解决方案，却不能同意一个包管理器来统治他们所有人。但我知道这可能永远不会发生，也可能不是一个好主意。

发行版维护者重新打包 python 包有点大胆。
甚至更大胆的 Python（和其他语言）开发人员将他们自己的包管理器安装到某人的发行版中。

我知道 python 不会费心去处理所有现有的包管理器及其边缘情况。
我希望有一些无缝的解决方案来将这些生态系统整合在一起。

是的，我感觉到你了。我通常将 pip 关闭我的系统（绝对从不以 root 身份运行它），除非在特殊情况下我出于某种原因被迫使用它，我只在虚拟环境中使用它。

通过这种方式，pacman 是唯一可以在我的系统上管理我的主目录之外的文件的东西（因为它应该是 imop）。

好吧，从 bCNC 开发人员的角度来看，我更喜欢每个人都使用 pip 安装 bCNC，因为这是我唯一可以直接支持的。我没有时间维护所有特定于发行版的软件包。

此外，如果存在 github 问题并且我修复了一些东西，我将其放在 pypi 上，因此即使是初学者也可以轻松升级它并立即测试修复，而无需等待他的发行版的维护者。（不是每个人都有带有 git 包的 AUR）。只要我们鼓励新用户使用 pip 安装 bCNC，他们都已经知道如何安装，并且可以在需要时正确升级。在此之前，人们正在运行几年前版本的发行版特定版本并报告错误。

有很多版本是可以的。例如，参见 svgelements。

目前我倾向于在 pypi 上发布很多。我什至会说我在每次提交/PR 后都会发布 pypi。许多这些版本只是实验性错误修复，我需要尽快将其提交给测试人员。将它们作为标签可能会让人们认为所有这些旧标签都应该被认为是稳定的。目前，任何 PyPI 版本基本上都只是为不能使用 git 的人提炼出来的 git master。您也可以只使用 git master 或任何随机提交，稳定性几乎没有差异。

虽然我认为大多数 pypi 版本都是合理的。多年来一直没有经过实际测试和“稳定”的版本。我计划在几天内完成 0.9.15。0.9.14.xx 版本是通往 0.9.15 的更多开发预发布版本。所以我真的不想引起他们的注意。

我完全理解您只能以 pypi 为目标，而不必为每个小发行版的特定包装特性而烦恼。我愿意接受你拥有的任何东西，并尝试做任何可能需要的工作来按照我认为应该用于 Arch 和朋友发行版的方式打包它。

如果您在 github 上使用的标签仅用于里程碑版本怎么办？你的开发版本和 pypi 上的一样吗？
例如，如果您使用的版本号格式为：XYZ 每当您碰到 X 或 Y 时，也许您可​​以将该标签放在这个 repo 中。我确信这样的事情对于您的 CI 是可编写脚本的。

如果您在 github 上使用的标签仅用于里程碑版本怎么办？

但这就是我目前所做的 我在 0.9.14 版本发布后加入了 bCNC，现在我们正在接近 0.9.15 标签。

另一方面，我确信会有很多 0.9.15.xx bugfix 版本值得包含到发行版中，因为 github 上有很多未解决的问题，我什至没有时间浏览所有这些（或者至少关闭已解决的和无效的）。

我认为标记某些东西是有意义的，例如。~0.9.15 发布后每月一次。一天生产 6 个 linux 软件包毫无意义……

@greyltc至于回复你最近创建的不必要的重复问题。这是我提出解决方案的地方，您同意了：

如果这对你来说还不够，请看我之前的评论：
#1341（评论）

你想在标签名称中重用“pypi”字符串而不是版本号字符串的原因是为了防止 github 标签页面被许多标签弄得乱七八糟？