Development cycle

This page describes the development cycle for the plugins in BoneJ2. The project follows an iterative model: the tools won't be written one by one from start to finish. Rather features are added little by little over several development cycles. For example, I'm first going to write the core algorithms in the Volume fraction plugin, and then later on add the option to limit the calculations to ROIs. I acknowledge that this page presents an idealised version of the development. In real life it often won't go so cleanly. For example, some details that need to be in the technical specification are only discovered during programming.

NB Cutting a new version of BoneJ2 for the update site, that is releasing to the users is a separate topic

Repeat for each plugin:

1. Write down specifications for the functionality that is going to be implemented in this cycle

• Both the wrapper and the ops

2. Plan a list of tasks from the specs
3. Design the integration tests (DINT) using the specs as a basis

• For example, decide to verify functionality against BoneJ1.

4. Create a new branch in the repository for the plugin
5. Implement code and write unit and regression tests

• In principle as much testing should be automated as possible. Regression tests are larger automated unit tests that may be too heavy to be run every time. They can be used to check that a (whole) plugin functions correctly, and produces correct results.
• This phase is not complete until mvn package passes

6. Perform integration tests (PINT)

• The tests shall be performed in an actual ImageJ environment. That is, plugins are added as packaged jar-files in the local ImageJ installation. This is easiest to do with mvn install.

7. Hide the corresponding BoneJ1 plugin if the new plugin is ready to supersede

• ImageJ1 plugins can be hid by changing plugins.config

8. Delete code marked @Deprecated in the previous cycle

• Note that if you delete public methods or classes, this changes the API. Version numbers of the Maven artefacts should change accordingly

9. Add @Deprecated annotations to code that has now become obsolete*
10. Update Maven artefacts' and POMs' version numbers
11. Merge with master
12. Check that Jenkins build succeeds
13. Write and publish a release notes

*Code may become obsolete either because it's reimplemented from BoneJ1 (Legacy module) to BoneJ2, or because it's migrated from BoneJ2 to core libraries like imagej-ops, scifio or scijava-common

The ops often get developed together with the wrapper, because it's easier to design the API and test functionality that way. After the ops mature they can be added to imagej-ops via pull requests. This two stage coding method may sometimes create a bit of additional work. Once the pull requests get accepted the ops can be removed from bonej-ops. BoneJ can start using them straight away by declaring a dependency on the SNAPSHOT version of imagej-ops. However, new versions of the affected BoneJ artefacts cannot be released until this dependency can be removed. Thus you have to wait for a new release of imagej-ops. If you are developing features that are not directly connected to the wrappers, say a support for file format to scifio, you can develop the component straight away without adding the code to BoneJ.

The cycle for adding functionality from BoneJ to other components

1. Fork the desired component and create a topic branch
2. Implement and unit test (or move already implemented functionality)
3. Check that mvn package succeeds
4. If the same functionality is in BoneJ2, remove it and alter dependent classes accordingly
5. Check that BoneJ2 unit and integration tests still pass
   • Change POMs to use the new SNAPSHOT version of the component as discussed above
   • Perform mvn install on both BoneJ2 and the component, and run ImageJ
6. Tidy up commit history
   • The fewer and tidier commits the better. Must have descriptive messages.
7. Create a pull request