I\'m having trouble determining a workflow for updating the version number of my R packages on github to avoid incorrectly named \"in-between\" versions. Here\'s what I do now.<
I highly recommend to follow the Git Flow branching model, where:
master
branch contains code of the latest stable release. Use version format x.y.z
develop
branch contains code under development. Use version format x.y.z-9000
Let master
be the default checkout branch on GitHub. That way users will always get the latest release, when they install R packages using:
install_github("owner/repos")
Users who wish to install the developers version, can use:
install_github("owner/repos@develop")
Next, if your package is also on CRAN, be strict and have master
reflect exactly what is on CRAN. That way the user install the same identical package version regardless whether they use:
install.packages("repos")
or
install_github("owner/repos")
This way people also see the same info regardless of they visit your CRAN page or your GitHub page. Moreover, you can rest assured that all users will see the same stable information / version, even if you tag along updating the develop
(only savvy users will be aware of this branch).
Next, when you release new versions, you can git tag
them with their version number, e.g.
git checkout master
git tag 1.2.3
git push --tags
That way users can install whatever version they'd like, e.g.
install_github("owner/repos@1.2.3")
Tools for this? The git flow extension is an awesome tool to orchestrate the above, e.g.
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
I've used the above on a daily basis for a good two years - I cannot imagine not using it.