Automating Version Increase of R Packages

Automating version increase of R packages

If you are using git, then you can use git tags to create a version string. This is how we generate the version string of our igraph library:

git describe HEAD --tags | rev | sed 's/g-/./' | sed 's/-/+/' | rev

It gives you a format like this:

0.8.0-pre+131.ca78343

0.8.0-pre is the last tag on the current branch. (The last released version was 0.7.1, and we create a -pre tag immediately after the release tag.) 131 is the number of commits since the last tag. ca78343 is the first seven character of the hex id of the last commit.

This would be great, except that you cannot have version strings like this in R packages, R does not allow it. So for R we transform this version string using the following script: https://github.com/igraph/igraph/blob/develop/interfaces/R/tools/convertversion.sh

Essentially it creates a version number that is larger than the last released version and smaller than the next versions (the one in the -pre tag). From 0.8.0-pre+131.ca78343 it creates

0.7.999-131

where 131 is the number of commits since the last release.

I put the generation of the DESCRIPTION file in a Makefile. This replaces the date, and the version number:

VERSION=$(shell ./tools/convertversion.sh)

igraph/DESCRIPTION: src/DESCRIPTION version_number
        sed 's/^Version: .*$$/Version: '$(VERSION)'/' $<     | \
        sed 's/^Date: .*$$/Date: '`date "+%Y-%m-%d"`'/' > $@

This is quite convenient, you don't need to do anything, except for adding the release tags and
the -pre tags.

Btw. this was mostly worked out by my friend and igraph co-developer, Tamás Nepusz, so the credit is his.

Versioning an R package with git/github?

I highly recommend to follow the Git Flow branching model, where:

• the master branch contains code of the latest stable release. Use version format x.y.z
• the 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.

R package - How to specify a dependency version that is only available on github (AKA dev version)

I think specifying this would solve your problem

Imports:
     Brobdingnag  (>= 1.2.8)
Remotes:
    RobinHankin/Brobdingnag@HEAD

Is there a way to automate reinstalling packages and their dependencies in r?

Some R packages really need recompilation after upgrade of R to a newer version. This could be your case. To reinstall and update these old packages (i.e. packages built under an earlier version of R) you can try to run this code in R console:

update.packages(ask = FALSE,
                checkBuilt = TRUE)

The ask parameter prevents R from constantly asking you to confirm every update of every package, while the checkBuilt parameter is to reinstall all packages built under an earlier version of R.

For more information see the documentation or type ?update.packages in your R console in RStudio. Hope this helps!

Pinning R package versions

To provide a little bit more information on packrat, which I use for this purpose. From the website.

R package dependencies can be frustrating. Have you ever had to use
trial-and-error to figure out what R packages you need to install to
make someone else’s code work–and then been left with those packages
globally installed forever, because now you’re not sure whether you
need them? Have you ever updated a package to get code in one of your
projects to work, only to find that the updated package makes code in
another project stop working?

We built packrat to solve these problems. Use packrat to make your R
projects more:

Isolated: Installing a new or updated package for one project won’t
break your other projects, and vice versa. That’s because packrat
gives each project its own private package library. Portable: Easily
transport your projects from one computer to another, even across
different platforms. Packrat makes it easy to install the packages
your project depends on. Reproducible: Packrat records the exact
package versions you depend on, and ensures those exact versions are
the ones that get installed wherever you go.

Packrat stores the version of the packages you use in the packrat.lock file, and then downloads that version from CRAN whenever you packrat::restore(). It is much lighter weight than devtools, but can still take some time to re-download all of the packages (depending on the packages you are using).

If you prefer to store all of the sources in a zip file, you can use packrat::snapshot() to pull down the sources / update the packrat.lock and then packrat::bundle() to "bundle" everything up. The aim for this is to make projects / research reproducible and portable over time by storing the package versions and dependencies used on the original design (along with the source code so that the OS dependency on a binary is avoided).

There is much more information on the website I linked to, and you can see current activity on the git repo. I have encountered a few cases that work in a less-than-ideal way (packages not on CRAN have some issues at times), but the git repo still seems to be pretty active with issues/patches which is encouraging.

How to set up automatic nuget version increments

How to set up automatic nuget version increments

If you want to automatic nuget version increments, you could use the BuildNumber $(Rev:r) instead of $(BuildID):

Run (build) number:

$(Rev:r)

2 (The third run on this day will be 3, and so on.)

Use $(Rev:r) to ensure that every completed build has a unique name.
When a build is completed, if nothing else in the build number has
changed, the Rev integer value is incremented by one.

If you want to show prefix zeros in the number, you can add additional
'r' characters. For example, specify $(Rev:rr) if you want the Rev
number to begin with 01, 02, and so on.

So, you could set the Build Number Format to $(Major).$(Minor)$(Rev:.r).

Hope this helps.

---

Related Topics