Development Workflow

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.

Fixing a bug, updating documentation, etc.

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
4. Create, document, and test code.
5. Working code can be merged into beta. (We need to decide if this will be done by the developer or via pull requests to a package moderator.)
6. 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.)
7. 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.

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