How to contribute

Contributions to StitchIt are welcome.

• Ideally you should fork the repository and send contributions as a pull request.

  StitchIt tends to be updated regularly, so keep your fork up to date or it will become difficult to merge your changes.

• New functions you add should have full help text e.g. like stitchSection.m

• If you modify the arguments in an existing function you should also update the function's help text.

• Many small commits are better than single big ones.

• Keep your pull requests clean. e.g. do not include commented-out test code code, temporary functions, or highly specialised functions such as stitchSection_BobsVersion.m. That includes adding your INI files or your post-acquisition functions. Such pull requests won't be accepted.

• Ideally use spaces instead of tabs for indenting.

• Read the developer notes

Branches

Development is distributed across three branches:

• master - Finalised code ready to be shared with others. Must be stable. Merge into here from prerelease.

• prerelease - Tested code that can be run on a live system but may have bugs. Merge into here from dev.

• dev - All development goes here. Unstable.

You should keep the number of commits low on master and prerelease. The development cycle goes as follows.

• Check out dev and ensure it's up to date with master and prerelease.

• Make changes and commit to dev.

• Perform basic tests. e.g. ensure no obvious bugs are present. Run any unit tests, should they be available, or write unit tests.

• List changes in the changelog. Assume the changelog will be read by users.

• Merge to prerelease with a merge-commit to keep things neat.

• Run the system on prerelease for a time to ensure no regressions are present.

• Merge prerelease into master with a merge-commit to keep things neat in the master branch.