Skip to content

Development Workflow

Jump to bottom
rpruim edited this page Jan 23, 2012 · 33 revisions

This is an outline of the workflow for development and maintenance of the mosaic package.

Dependencies

Maintainers will need the following available to follow this workflow completely.

  • scripting languages: R, bash, perl,
  • R packages for development: devtools, testthat, optparse, roxygen2
  • R packages for the package itself: lattice, grid, methods, Hmisc, utils, MASS, reshape2, [manipulate]
  • R packages to compile ancillary materials (e.g. books): knitr

Currently, it is assumed that all scripts are run from the parent directory of bin. For example, ./bin/doitall

Github workflow

This outline is still in progress. git code examples will be added eventually.

Creating new functionality

  1. Create an issue at github describing the new feature to be added and assign the issue to the person doing the coding.

  2. Make sure what you have locally is up to date

git fetch    # safer than git pull in that it allows/requires you to do the merging manually

or

git pull     # this will do any necessary merging that can happen without your intervention
  1. Create a branch named after the issue number (e.g., issue001). Pad to 3 digits.
    Typically this branch will come off of the beta branch or one of its subbranches.
git checkout beta     # change to beta branch
git status            # make sure everything looks as it should
git branch issue001   # create the new topic branch to work in
git checkout issue001 # switch to the new branch

The last two commands can be combined into

git checkout -b issue001

At this point, the new topic branch is only on your local machine.

  1. Create, document, and test code, committing from time to time as you work.
git commit
# do some stuff
git commit
  • Whenever possible, new code should result in new examples, new unit tests, or both.
  • First line of commit message should be a short description of committed work. Second line should be blank. The next few lines can add additional details.
  • Avoid committing too many things all at once. Commits are cheap.

  1. When ready for public release, beta can be merged into master (We need to decide if this will done by the developer or via pull requests to a package moderator.)

  2. Prior to merging beta into master, it may be useful to have an alpha branch that will become the next beta so that we can continue working on new stuff without delaying the release of more mature code.

Fixing a bug, updating documentation, etc.

But fixes are similar except that those for which immediate deployment is desired could be done in master rather than beta.

CRAN submission

When master is rebuilt, the resulting package should have a new R version number and be submitted to CRAN.

Building and Checking the Package

Clone this wiki locally