Skip to content

Development cycle

Jump to bottom
Richard Domander edited this page Nov 24, 2018 · 13 revisions

This page outlines the standard BoneJ development process. It also details how the process differs, when working on a fork of an external repository (or when a developer outside bonej-org wants to contribute to our repository).

BoneJ development cycle

  1. Create a topic branch for the fix/new feature
  2. Write code and unit tests
  • Keep commits small - one commit does one thing
  • Each commit in the history should build
  • Changing formatting should happen in different commits than actual coding
  1. If necessary, write complementary wrapper and manual tests
  2. Check that code builds and tests pass on your computer by running mvn clean package
  • If you've added wrapper tests, run mvn clean package -PallTests instead
  1. Add Javadoc (at least) for public methods, fields and classes
  • Check that Javadoc is valid with mvn javadoc:javadoc
  1. Create a pull request and wait for it to be reviewed
  2. The PR can be merged when
  • Review is complete
  • Travis build passes
  • There are no merge conflicts

For very small changes such as fixing a typo, or updating README.md the above process is too heavy-handed. Those kinds of commits can be pushed directly to the master.

Developing a fork

Developing on a fork is very similar to developing the repository itself. It just has a few additional pre-requirements:

  1. Create the fork (instructions)
  2. Synchronize the fork

If you're working on a fork of an external repository, such as imagej-ops it's up to the maintainers of that repository to decide when to review your PR, and whether to accept and merge it at all. You should also conform to their guidelines, code style etc.

Clone this wiki locally