Contributions to BakingTray are welcome.

  • New functions you add should have detailed help text like that in 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, temporary functions, or highly specialised functions such as BakingTray_forMyRigOnTuesdays.m.

  • Do not add your own INI files, recipe files, or other settings files. The SETTINGS and SETTINGS_BACKUP directories must be empty but for the .gitignore file.

  • Use spaces instead of tabs for indenting.


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.

Last updated