使用git / github对R包进行版本控制？

Question

我无法确定更新github上我的R软件包版本号的工作流程，以避免错误地命名为“中间”版本。这就是我现在所做的。

• 例如，提交并推送版本1.0.0，并将版本设置为1.0.0
• 提交并推送一些错误修复等，而无需更改DESCRIPTION文件
• 最终决定我应该将版本提升到1.0.1，然后提交并推送更新的描述，然后设置新版本。

这个问题是，如果有人（比方说我）在我做了一些修复之后从github下载但是在我碰到版本之前，他们认为他们拥有的版本是1.0.0（因为这仍然是描述中的内容） ）但它真的有1.0.0和1.0.1之间的东西。

这样的事情似乎在“Is it possible to add a version number using git / github”这个问题上进行了讨论，但是并不是特定于R，所以无论如何我都无法判断它是否在谈论同样的事情或者如何实现R，无论如何。

还有一个问题“Automating version increase of R packages”有一个自动更新它的答案，虽然在评论中，我们看到Hadley“基本上没有出售自动递增版本的好处”（https://github.com/hadley/devtools/issues/501）。那里的代码也取决于Make所以不是跨平台的。

Answer 1

我强烈建议遵循Git Flow分支模型，其中：

• master分支包含最新稳定版本的代码。使用版本格式x.y.z
• develop分支包含正在开发的代码。使用版本格式x.y.z-9000

让master成为GitHub上的默认结帐分支。这样，当用户使用以下命令安装R软件包时，用户将始终获得最新版本：

install_github("owner/repos")

希望安装开发人员版本的用户可以使用：

install_github("owner/repos@develop")

接下来，如果您的软件包也在CRAN上，请严格并让master准确反映CRAN上的内容。这样，无论用户是否使用，用户都会安装相同的相同包版本：

install.packages("repos")

要么

install_github("owner/repos")

这样人们也可以看到相同的信息，无论他们访问您的CRAN页面还是您的GitHub页面。此外，您可以放心，所有用户都会看到相同的稳定信息/版本，即使您标记更新develop（只有精明的用户才会知道这个分支）。

接下来，当您发布新版本时，您可以使用其版本号来git tag，例如

git checkout master
git tag 1.2.3
git push --tags

这样，用户可以安装他们喜欢的任何版本，例如

install_github("owner/[email protected]")

这个工具？ git flow扩展是一个很好的工具来协调上面的，例如，

git checkout develop
git flow release start 1.2.4
emacs DESCRIPTION ## Update version x.y.z-9000 -> x.y.z+1
R CMD build ...
R CMD check ...
git flow release finish 1.2.4
git checkout master
git push
git push --tags
git checkout develop
emacs DESCRIPTION ## Bump version to x.y.(z+1)-9000
git commit -am "Bump develop version [ci skip]"
git push

我已经每天使用上面的两年了 - 我无法想象不使用它。

Answer 2

我认为一个建议密切关注您当前的工作流程：

• 提交并推送版本1.0.0并将“github release”设置为1.0.0后，创建一个开发版本并将DESCRIPTION文件版本更改为1.0.0.9000。
• 然后，当您修复错误等时，您应该移动开发版本号 描述文件转发到9001, 9002, ..., n。不要做“github发布”。
• 准备好后，删除.9000并将版本提升到1.0.1，推送更新的描述，并设置一个新的“github版本”。

这是借用他在R Packages的书中提供的Hadley解决方案。

“而是总是使用。来分隔版本号。发布的版本号由三个数字组成，...对于版本号1.9.2,1是主要号码，9是次要号码，2是补丁号码。从不使用像1.0这样的版本，而不是总是拼出三个组件，1.0.0。“

“开发中的软件包有第四个组件：开发版本。这应该从9000开始。例如，软件包的第一个版本应该是0.0.0.9000。这个建议有两个原因：首先，它使它变得容易查看包是否已发布或正在开发中，第四位的使用意味着您不限于下一个版本的内容.0.0.1,0.1.0和1.0.0都大于0.0 .0.9000“。

“如果您添加了另一个开发包需要依赖的重要功能，则增加开发版本，例如从9000增加到9001。”

http://r-pkgs.had.co.nz/description.html#version

关于发布包裹的另一节他说：

“如果您一直在遵循版本控制方面的建议，那么开发中软件包的版本号将包含四个组件major.minor.patch.dev，其中dev至少为9000.数字9000是任意的，但提供了强大的视觉信号这个版本号有些不同。发布的软件包没有开发组件，所以现在你需要删除它并根据你所做的更改选择一个版本号。例如，如果当前版本是0.8.1.9000将下一个CRAN版本为0.8.2,0.9.0或1.0.0“