How to contribute
Last updated
Was this helpful?
Last updated
Was this helpful?
Contributions to StitchIt are welcome.
Ideally you should .
StitchIt tends to be updated regularly, so keep your fork up to date .
New functions you add should have full help text e.g. like
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
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.