Skip to main content
Thank you for your interest in contributing to MindsDB. MindsDB is free, open-source software and all types of contributions are welcome, whether they’re documentation changes, bug reports, bug fixes, or new source code changes.
In order to contribute to MindsDB:
  • fork the MindsDB GitHub repository,
  • install MindsDB locally,
  • implement and test your changes,
  • push your changes to the develop branch.
  1. Fork the MindsDB repository from MindsDB GitHub.
  2. Clone the MindsDB repository locally from your fork and go inside the repository folder. 
    cd /path/mindsdb-repo-folder-name
  3. Fetch all other branches from the MindsDB repository with these commands: 
    git remote add upstream https://github.com/mindsdb/mindsdb

git fetch upstream
  4. Switch to the develop branch. 
    git checkout develop
  5. Create a new branch for your changes from the develop branch. 
    git checkout -b new-branch-name
  6. Make your changes on this branch.
  7. Commit and push your changes to GitHub. 
    git add *

git commit -m "commit message"

git push --set-upstream origin new-branch-name
  8. Go to GitHub and create a PR to the develop branch of the MindsDB repository.

​
MindsDB Release Process

The main branch of the MindsDB repository contains the latest stable version of MindsDB and represents the GA (General Availability) release. Learn more about MindsDB release types here. MindsDB follows the Gitflow branching model to manage development and releases as follows.
1

Development Phase

All code changes are first committed to the develop branch.
2

Release Preparation

When a release is approaching, a short-lived release branch is created from the develop branch.
  • This branch is used for final testing and validation.
  • Pre-GA artifacts are built at this stage, including both the Python package and the Docker image, and shared for broader testing and feedback.
3

Release Finalization

After successful testing and validation:
  • The release branch is merged into the main branch, making it an official GA release.
  • The final GA versions of the Python package and Docker image are released, while the pre-GA version are removed.

​
Contributor Testing Requirements

As a contributor, you are responsible for writing the code according to the Python Coding Standards and thoroughly testing all features or fixes that you implement before they are merged into the develop branch.

​
Feature Branch Testing

Before merging your changes, the following types of testing must be completed to validate your work in isolation:
  • Unit Tests Verify that individual components or functions behave as expected during development.
  • Integration Tests Ensure that your new code works correctly with existing functionality and doesn’t introduce regressions.

​
Post-Release Testing

After a release that includes your features or fixes is published, contributors are encouraged to:
  • Test their changes in the released environment, and
  • Report any issues or unexpected behavior that may arise.