|
| 1 | +# Contributing to the Microsoft Graph Core SDK for Python |
| 2 | + |
| 3 | +The Microsoft Graph SDK for python is available for all manner of contribution. There are a couple of different recommended paths to get contributions into the released version of this SDK. |
| 4 | + |
| 5 | +__NOTE__ A signed a contribution license agreement is required for all contributions, and is checked automatically on new pull requests. Please read and sign [the agreement](https://cla.microsoft.com/) before starting any work for this repository. |
| 6 | + |
| 7 | +## File issues |
| 8 | + |
| 9 | +The best way to get started with a contribution is to start a dialog with the owners of this repository. Sometimes features will be under development or out of scope for this SDK and it's best to check before starting work on contribution. |
| 10 | + |
| 11 | +## Submit pull requests for trivial changes |
| 12 | + |
| 13 | +If you are making a change that does not affect the interface components and does not affect other downstream callers, feel free to make a pull request against the __main__ branch. The main branch will be updated frequently. |
| 14 | + |
| 15 | +Revisions of this nature will result in a 0.0.X change of the version number. |
| 16 | + |
| 17 | +## Submit pull requests for features |
| 18 | + |
| 19 | +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. |
| 20 | + |
| 21 | +Revisions of this nature will result in a 0.X.X change of the version number. |
| 22 | + |
| 23 | +## Commit message format |
| 24 | + |
| 25 | +To support our automated release process, pull requests are required to follow the [Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/) |
| 26 | +format. |
| 27 | + |
| 28 | +Each commit message consists of a **header**, an optional **body** and an optional **footer**. The header is the first line of the commit and |
| 29 | +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. |
| 30 | + |
| 31 | +``` |
| 32 | +<type>[optional scope]: <short description> |
| 33 | +<BLANK LINE> |
| 34 | +<optional body> |
| 35 | +<BLANK LINE> |
| 36 | +<optional footer(s)> |
| 37 | +``` |
| 38 | + |
| 39 | +The recommended commit types used are: |
| 40 | + |
| 41 | + - **feat** for feature updates (increments the _minor_ version) |
| 42 | + - **fix** for bug fixes (increments the _patch_ version) |
| 43 | + - **perf** for performance related changes e.g. optimizing an algorithm |
| 44 | + - **refactor** for code refactoring changes |
| 45 | + - **test** for test suite updates e.g. adding a test or fixing a test |
| 46 | + - **style** for changes that don't affect the meaning of code. e.g. formatting changes |
| 47 | + - **docs** for documentation updates e.g. ReadMe update or code documentation updates |
| 48 | + - **build** for build system changes (gradle updates, external dependency updates) |
| 49 | + - **ci** for CI configuration file changes e.g. updating a pipeline |
| 50 | + - **chore** for miscallaneous non-sdk changesin the repo e.g. removing an unused file |
| 51 | + |
| 52 | +Adding a footer with the prefix **BREAKING CHANGE:** will cause an increment of the _major_ version. |
| 53 | + |
0 commit comments