|
| 1 | +# Shapeshifter Library contributing guide |
| 2 | + |
| 3 | +Thank you for investing your time in contributing to our project! |
| 4 | + |
| 5 | +## Table of contents |
| 6 | +1. [Reporting bugs](#reporting-bugs) |
| 7 | +2. [Requesting features](#requesting-features) |
| 8 | +3. [Contributing code](#contributing-code) |
| 9 | +4. [Releasing new versions](#releasing-new-versions) |
| 10 | +5. [Code of conduct](#code-of-conduct) |
| 11 | + |
| 12 | +## Reporting bugs |
| 13 | + |
| 14 | +To be described. |
| 15 | + |
| 16 | +## Requesting features |
| 17 | + |
| 18 | +To be described. |
| 19 | + |
| 20 | +## Contributing code |
| 21 | + |
| 22 | +To be described. |
| 23 | + |
| 24 | +## Releasing new versions |
| 25 | + |
| 26 | +We use [semantic versioning](https://semver.org). |
| 27 | + |
| 28 | +Given a version number MAJOR.MINOR.PATCH, increment the: |
| 29 | + - MAJOR version when you make incompatible API changes |
| 30 | + - MINOR version when you add functionality in a backward compatible manner |
| 31 | + - PATCH version when you make backward compatible bug/security fixes |
| 32 | + |
| 33 | +### Major or minor release |
| 34 | +Whatever the version in the `pom.xml` is, that is the version that will be released. |
| 35 | + |
| 36 | +For example if the version in the pom.xml is `1.0.0-SNAPSHOT`, then the released version will be `1.0.0`: |
| 37 | +1. Trigger the `release` workflow on the `main` branch. |
| 38 | +2. This will build and upload version `1.0.0` to the Maven repository and will set the next development version on the branch to `1.1.0-SNAPSHOT`. |
| 39 | + |
| 40 | +By default, the minor version will be incremented. If you want to release or start work on a new major version, you will have to update the `pom.xml` to the new major version (appending `-SNAPSHOT`) before triggering the workflow. |
| 41 | + |
| 42 | +### Security / bug fix release |
| 43 | +Let's assume the last release was `1.0.0` and you want to make a security or bug fix on it. |
| 44 | + |
| 45 | +1. Create a new branch from the tag `v1.0.0`, e.g. `v1.0.x` (name can be anything). |
| 46 | +2. Update the version in the pom.xml to `1.0.1-SNAPSHOT`. |
| 47 | +3. Make your changes and commit them. |
| 48 | +4. Trigger the `release` workflow on the `v1.0.x` branch. |
| 49 | +5. This will build and upload version `1.0.1` to the Maven repository and will set the next development version on the branch to `1.0.2-SNAPSHOT`. |
| 50 | +6. Merge the branch `v1.0.x` into `main`. |
| 51 | + |
| 52 | +You can keep the branch open to make more bug/security fixes and releases on the `v1.0.x` branch, or you can delete the branch when no longer needed. |
| 53 | + |
| 54 | +This can be done for any previous release (including patch versions). |
| 55 | + |
| 56 | +## Code of conduct |
| 57 | + |
| 58 | +To be described. |
0 commit comments