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.

  2. Assign the issue to the person doing the coding.

  3. 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

At this point, the 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. Working code can be merged into beta.

  2. 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.)

  3. 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