chore: add info about release-please to contributing guidelines

Author: senthurayyappan

CONTRIBUTING.md

@@ -134,6 +134,155 @@ git push origin name-of-your-bugfix-or-feature
 
 11. Submit a pull request through the GitHub website.
 
+# Commit Message Guidelines
+
+This project uses [Conventional Commits](https://www.conventionalcommits.org/) for commit messages and [Release Please](https://github.com/googleapis/release-please) for automated releases.
+
+## Conventional Commit Format
+
+Commit messages should follow this format:
+
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+### Types
+
+- `feat`: A new feature
+- `fix`: A bug fix
+- `docs`: Documentation only changes
+- `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+- `refactor`: A code change that neither fixes a bug nor adds a feature
+- `perf`: A code change that improves performance
+- `test`: Adding missing tests or correcting existing tests
+- `build`: Changes that affect the build system or external dependencies
+- `ci`: Changes to CI configuration files and scripts
+- `chore`: Other changes that don't modify src or test files
+- `revert`: Reverts a previous commit
+
+### Examples
+
+```bash
+feat: add support for new actuator model
+fix: resolve memory leak in joint controller
+docs: update installation instructions
+refactor: simplify sensor calibration logic
+test: add unit tests for PID controller
+```
+
+### Breaking Changes
+
+Breaking changes should be indicated by adding `!` after the type/scope or by including `BREAKING CHANGE:` in the footer:
+
+```bash
+feat!: remove deprecated API methods
+# or
+feat: add new configuration format
+
+BREAKING CHANGE: Configuration file format has changed from JSON to YAML
+```
+
+## Release Please
+
+This project uses Release Please to automatically:
+
+- Generate changelogs
+- Create releases
+- Update version numbers
+- Publish to PyPI
+- Deploy documentation
+
+Release Please analyzes conventional commit messages to determine the type of release (major, minor, or patch) and generates appropriate release notes. This happens automatically when commits are pushed to the main branch.
+
+### How Release Please Works
+
+1. **On every push to main**: Release Please analyzes new commits using conventional commit format
+2. **Creates/updates a Release PR**: If releasable changes are found, it creates or updates a "chore: release X.Y.Z" PR
+3. **When Release PR is merged**: A GitHub release is created and the package is automatically published to PyPI
+
+### Avoiding Unintended Releases
+
+If you need to commit to main without triggering a release (for urgent fixes, documentation, etc.), use these strategies:
+
+#### Skip Release Processing
+
+Add `Release-As: skip` to your commit message:
+
+```bash
+git commit -m "docs: fix typo in contributing guide
+
+Release-As: skip"
+```
+
+#### Use Non-Release Commit Types
+
+Some commit types don't trigger releases by default:
+
+- `chore`: Maintenance tasks
+- `ci`: CI/CD changes
+- `build`: Build system changes
+- `docs`: Documentation-only changes (depending on configuration)
+
+```bash
+git commit -m "chore: update GitHub Actions workflow"
+```
+
+### Manual Release Control
+
+#### Force a Specific Version
+
+Override the automatic version bump:
+
+```bash
+git commit -m "feat: add new actuator support
+
+Release-As: 2.1.0"
+```
+
+#### Force a Patch Release
+
+Convert a non-release commit into a patch release:
+
+```bash
+git commit -m "docs: improve API documentation
+
+Release-As: patch"
+```
+
+### Working with Release Please PRs
+
+When Release Please creates a release PR:
+
+1. **Review the changelog**: Ensure all changes are accurately described
+2. **Check the version bump**: Verify it matches the significance of changes
+3. **Merge to release**: Merging the PR will create the GitHub release and publish to PyPI
+4. **Never close without merging**: This will skip the release entirely
+
+The release PR will also trigger a test publication to Test PyPI for validation.
+
+### Troubleshooting
+
+**No Release PR created?**
+
+- Ensure commits follow conventional commit format exactly
+- Check that commits aren't marked with `Release-As: skip`
+- Verify there isn't already an open Release Please PR (only one can exist)
+
+**Wrong version bump?**
+
+- `fix:` commits create patch releases (0.0.1)
+- `feat:` commits create minor releases (0.1.0)
+- Breaking changes (with `!` or `BREAKING CHANGE:`) create major releases (1.0.0)
+
+**Need to cancel a release?**
+
+- Close the Release Please PR (don't merge it)
+- The next qualifying commit will create a new release PR
+
 # Pull Request Guidelines
 
 Before you submit a pull request, check that it meets these guidelines:

docs/contributing.md

@@ -134,6 +134,146 @@ git push origin name-of-your-bugfix-or-feature
 
 11. Submit a pull request through the GitHub website.
 
+# Commit Message Guidelines
+
+This project uses [Conventional Commits](https://www.conventionalcommits.org/) for commit messages and [Release Please](https://github.com/googleapis/release-please) for automated releases.
+
+## Conventional Commit Format
+
+Commit messages should follow this format:
+
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+### Types
+
+- `feat`: A new feature
+- `fix`: A bug fix
+- `docs`: Documentation only changes
+- `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+- `refactor`: A code change that neither fixes a bug nor adds a feature
+- `perf`: A code change that improves performance
+- `test`: Adding missing tests or correcting existing tests
+- `build`: Changes that affect the build system or external dependencies
+- `ci`: Changes to CI configuration files and scripts
+- `chore`: Other changes that don't modify src or test files
+- `revert`: Reverts a previous commit
+
+### Examples
+
+```bash
+feat: add support for new actuator model
+fix: resolve memory leak in joint controller
+docs: update installation instructions
+refactor: simplify sensor calibration logic
+test: add unit tests for PID controller
+```
+
+### Breaking Changes
+
+Breaking changes should be indicated by adding `!` after the type/scope or by including `BREAKING CHANGE:` in the footer:
+
+```bash
+feat!: remove deprecated API methods
+# or
+feat: add new configuration format
+
+BREAKING CHANGE: Configuration file format has changed from JSON to YAML
+```
+
+## Release Please
+
+This project uses Release Please to automatically:
+- Generate changelogs
+- Create releases
+- Update version numbers
+- Publish to PyPI
+- Deploy documentation
+
+Release Please analyzes conventional commit messages to determine the type of release (major, minor, or patch) and generates appropriate release notes. This happens automatically when commits are pushed to the main branch.
+
+### How Release Please Works
+
+1. **On every push to main**: Release Please analyzes new commits using conventional commit format
+2. **Creates/updates a Release PR**: If releasable changes are found, it creates or updates a "chore: release X.Y.Z" PR
+3. **When Release PR is merged**: A GitHub release is created and the package is automatically published to PyPI
+
+### Avoiding Unintended Releases
+
+If you need to commit to main without triggering a release (for urgent fixes, documentation, etc.), use these strategies:
+
+#### Skip Release Processing
+Add `Release-As: skip` to your commit message:
+
+```bash
+git commit -m "docs: fix typo in contributing guide
+
+Release-As: skip"
+```
+
+#### Use Non-Release Commit Types
+Some commit types don't trigger releases by default:
+- `chore`: Maintenance tasks
+- `ci`: CI/CD changes
+- `build`: Build system changes
+- `docs`: Documentation-only changes (depending on configuration)
+
+```bash
+git commit -m "chore: update GitHub Actions workflow"
+```
+
+### Manual Release Control
+
+#### Force a Specific Version
+Override the automatic version bump:
+
+```bash
+git commit -m "feat: add new actuator support
+
+Release-As: 2.1.0"
+```
+
+#### Force a Patch Release
+Convert a non-release commit into a patch release:
+
+```bash
+git commit -m "docs: improve API documentation
+
+Release-As: patch"
+```
+
+### Working with Release Please PRs
+
+When Release Please creates a release PR:
+
+1. **Review the changelog**: Ensure all changes are accurately described
+2. **Check the version bump**: Verify it matches the significance of changes
+3. **Merge to release**: Merging the PR will create the GitHub release and publish to PyPI
+4. **Never close without merging**: This will skip the release entirely
+
+The release PR will also trigger a test publication to Test PyPI for validation.
+
+### Troubleshooting
+
+**No Release PR created?**
+- Ensure commits follow conventional commit format exactly
+- Check that commits aren't marked with `Release-As: skip`
+- Verify there isn't already an open Release Please PR (only one can exist)
+
+**Wrong version bump?**
+- `fix:` commits create patch releases (0.0.1)
+- `feat:` commits create minor releases (0.1.0)
+- Breaking changes (with `!` or `BREAKING CHANGE:`) create major releases (1.0.0)
+
+**Need to cancel a release?**
+- Close the Release Please PR (don't merge it)
+- The next qualifying commit will create a new release PR
+
 # Pull Request Guidelines
 
 Before you submit a pull request, check that it meets these guidelines: