Update contributing

CONTRIBUTING.md

@@ -19,3 +19,34 @@ Revisions of this nature will result in a 0.0.X change of the version number.
 If major functionality is being added, or there will need to be gestation time for a change, it should be submitted against the __feature__ branch.
 
 Revisions of this nature will result in a 0.X.X change of the version number.
+
+## Commit message format
+
+To support our automated release process, pull requests are required to follow the [Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/)
+format.
+
+Each commit message consists of a **header**, an optional **body** and an optional **footer**. The header is the first line of the commit and
+MUST have a **type** (see below for a list of types) and a **description**. An optional **scope** can be added to the header to give extra context.
+
+```
+<type>[optional scope]: <short description>
+<BLANK LINE>
+<optional body>
+<BLANK LINE>
+<optional footer(s)>
+```
+
+The recommended commit types used are:
+
+ - **feat** for feature updates (increments the _minor_ version)
+ - **fix** for bug fixes (increments the _patch_ version)
+ - **perf** for performance related changes e.g. optimizing an algorithm
+ - **refactor** for code refactoring changes
+ - **test** for test suite updates e.g. adding a test or fixing a test
+ - **style** for changes that don't affect the meaning of code. e.g. formatting changes
+ - **docs** for documentation updates e.g. ReadMe update or code documentation updates
+ - **build** for build system changes (gradle updates, external dependency updates)
+ - **ci** for CI configuration file changes e.g. updating a pipeline
+ - **chore** for miscallaneous non-sdk changesin the repo e.g. removing an unused file
+
+Adding a footer with the prefix **BREAKING CHANGE:** will cause an increment of the _major_ version.