All development should be done in the
develop branch of the package GithHub repository. The aim should be to have a workable version in
develop branch, so make sure your package passes R CMD check locally before pushing to the
The head of the
master branch should be the latest released version of the package. No changes should be directly pushed to the
All branches are monitored by Github Actions. Github Actions is a continuous integration system, meaning that any change pushed to one of the branches triggers the package to be built, and R CMD check to be performed. Any warnings or errors that occur during this process will cause an e-mail to be sent to the package maintainers. To implement continuous integration using Github Actions HADES package maintainers need to
EvidenceSynthesis repo, copy these files into the new repository in their respective subfolders:
Add these lines to your
.Rbuildignore file if they are not already there:
.github deploy.sh compare_versions
Add a build status badge to
git commit, and
git push the new files.
Ensure that Github Actions are executing by visiting:
Each package has a three-digit version number.
New micro versions (e.g. from 4.3.2 to 4.3.3) indicate bug fixes only. No new functionality, and forward and backward compatibility are guaranteed
New minor versions (e.g. from 4.3.3 to 4.4.0) indicate added functionality. Only backward compatibility is guaranteed
New major versions (e.g. from 4.4.0 to 5.0.0) indicate major revisions. All bets are off in terms of compatibility
Only the package maintainer may create a new release. The release should be prepared in the
develop branch. The following steps are mandatory:
Update the package meta-data
Regenerate the documentation. This includes the following steps. Note that the
extras/PackageMaintenance.R file should contain the code needed to perform most of these steps:
pkgdown, and fix the HADES logo using
Make sure the package passes R check without warnings, both locally and on Github Actions. Fix as many Notes as possible.
For those packages that go into CRAN: Check the package using
devtools::check_rhub(), and submit to CRAN using
Once all these steps are completed and commited to the
develop branch, the package can be released by merging
Pushing changes to the
master branch where the version number in the DESCRIPTION file is higher than the current one will trigger the automated release process. If the package passes R check, the following steps are automatically performed:
A new release and tag are created in the GitHub repo with the version number.
The package is pushed to the OHDSI
Announce the new release on the OHDSI Forums HADES development announcements thread, providing a short summary of hte most important changes in the new release.