Contributing

Contributions to BakingTray are welcome.
You should fork the repository and send contributions as a pull request and keep your fork up to date or it will become difficult to merge your changes.
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. 
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. 
Last modified 1yr ago