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.
- 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
andSETTINGS_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 fromprerelease
.prerelease
- Tested code that can be run on a live system but may have bugs. Merge into here fromdev
.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 withmaster
andprerelease
. - 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
intomaster
with a merge-commit to keep things neat in the master branch.
Last modified 1yr ago