From a4523812547d0c3e76326b96be5c8d40848bd75d Mon Sep 17 00:00:00 2001 From: shemogumbe Date: Wed, 26 Jun 2024 14:11:19 +0300 Subject: [PATCH] update contributing guide-add commit format --- CONTRIBUTING.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 171a7e12af0..cfc6e273fcd 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -11,6 +11,37 @@ The best way to get started with a contribution is to start a dialog with us. So ## Pull requests All pull requests should be submitted against the **dev** branch or a specific feature branch. The master branch is intended to represent the code released in the most-recent Nuget package. +## 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. + +``` +[optional scope]: + + + + +``` + +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. + When a new package is about to be released, changes in dev will be merged into master. The package will be generated from master. Some things to note about this project: