Skip to content

Developer's Guide

Jump to bottom
Evyn Machi edited this page Apr 19, 2022 · 33 revisions

Welcome to the texasholdem developer's guide!

Contributing

Want a new feature, found a bug, or have questions? Feel free to add to our issue board on Github! Open Issues.

We welcome any developer who enjoys the package enough to contribute! Please message me at evyn.machi@gmail.com if you want to be added as a contributor.

Feel free to create a fork and open a PR!

Local Developing & Testing

We prefer using poetry for building, testing, and publishing.

Build & Test

Update the poetry.lock file and install the project with

poetry update

To test the package

poetry run pytest

To lint the package

poetry run pylint texasholdem/ test/

Branching Model

The main branch is the latest developmental branch which includes the most recent commits for new features / incremental updates for new features.

In addition to the main branch, we have release branches of the form {major}.{minor}, e.g. 0.1, 1.2. These versions represent adding a new supported feature to the package for release. We generally bump the minor version for new features and the major version for major changes and breaking changes.

Adding a New Feature

To add a new feature, developers make a topic branch based off the main branch, and make a PR against the same that contains 1 commit with the feature. Generally, most PRs and features should have an issue number associated with it with few, rare exceptions.

Definition of Done

When a PR is opened, we require the following in order to merge:

  • An issue is mentioned and linked
  • 1 approving review has been made
  • All status checks pass

Release Process

Release a New Version

Say the current version of the package in pypi is 0.6.2 and we want to release 0.7.0.

Then, we take the following steps:

  1. Push the new release branch 0.7 with the commit we want to release.
  2. Bump all the versions in the package to the next release number (e.g. 0.7.0) (See version bumping for all the places that need a version bump.)
  3. Create a Github release, tagging the HEAD of the 0.7 branch with the new tag 0.7.0.
    1. Make sure to review the changes since the last version and update the change log in the release. See the previous releases for examples.
    2. Make sure as well to update the Changelog in the README.md and in docs/index.rst.
  4. Publish the release which should automatically upload to pypi via Github actions.

Version Bumping

The following places in the package should be version bumped:

  1. pyproject.toml.
  2. README.md has a few spots in the overview of the package to bump, all in links and text.
  3. docs/conf.py under the release variable.

Note: we are working on making this an automatic process.

Fixes & Backports

Say after we have just released 0.7.0, we need to fix a bug introduced in version 0.6.2. We would go through the following steps:

  1. Create a fix based off the 0.6 release branch (which should have the tag 0.6.2 on the latest commit) and create a PR against the same.
  2. Wait until your fix PR has completed the Github checks.
    1. In order, create PRs with the fix cherry-picked against all release branches >= 0.6 and including main.
    2. For each release branch / PR, add a version bump commit for that branch (e.g.0.6.2 -> 0.6.3 for the 0.6 branch, 0.7.{n} -> 0.7.{n+1} for the 0.7 branch.
    3. Merge the PR once all the checks complete.
    4. Cherry-pick the fix and make a new PR against the next release branch.
  3. Create Github releases for each release branch with the corresponding release number.
Clone this wiki locally