Dependency Policy

This page documents how drf-flex-fields2 manages dependency updates.

Runtime Dependencies

drf-flex-fields2 is intentionally small. At runtime it only relies on:

  • Django

  • Django REST Framework

No other runtime dependencies are required.

Because this project is a reusable library rather than an application, runtime ranges are kept deliberately wide and only minimum versions are defined.

Open ranges for runtime dependencies

Since Django and Django REST Framework are imported in the library code, they are treated as runtime dependencies under Python packaging best practices.

The minimum versions are tracked by policy and currently set to:

  • Django >= most recent LTS release

  • Django REST Framework >= major release from about one year ago

  • Python: last three versions

For Django REST Framework, the second segment (for example the 16 in 3.16) is treated as the effective major line for compatibility planning, because the first segment changes infrequently.

No upper bounds are set for runtime dependencies. The default expectation is forward compatibility with newer Django and Django REST Framework releases. If an upstream release introduces an incompatibility, it is detected proactively through CI and a compatibility update is published.

Non-Runtime Dependencies

Development and documentation dependencies are treated differently. They are not part of the library’s public compatibility contract, so they are generally bumped to the most recent available version.

This applies to dependencies such as:

  • test and coverage tooling

  • Sphinx and documentation extensions

  • GitHub Actions dependencies

Semi-Automated Updates With Renovate

Renovate regularly checks the repository for dependency updates. Renovate is run by .github/workflows/run-renovate.yml (scheduled weekly and available through manual dispatch). The strategy is:

  • Runtime dependencies (Django, Django REST Framework, Python) are tracked as manual work through the Dependency Dashboard issue and draft PRs. Maintainers perform runtime range and matrix updates manually.

  • A dedicated latest-versions.txt file is used as a release tracker for Python, Django, and Django REST Framework. Renovate watches this file and opens draft PRs whenever a newer upstream release is available. When reviewing these PRs do the following:

    • Check, if the minimum supported version should be bumped.

    • Update the minimum supported versions in pyproject.toml.

    • Update the minimum and maximum versions in noxfile.py.

    • Update the Python versions in .github/workflows/run-tests-full.yml.

    • Commit the version bumps to the PR and check, if tests pass.

Occasionally the trove classifiers in pyproject.toml need to be updated, too.

  • Non-runtime Poetry dependencies are pinned to exact versions and auto-merged after required status checks pass.

  • GitHub Actions dependencies are updated and auto-merged after required status checks pass.

When Renovate opens an auto-merge pull request, required repository checks must pass before merge.

Runtime dependency reminder pull requests are intentionally draft pull requests and include a maintainer checklist in the PR body. They are not auto-merged.

Test Strategy For Dependency Updates

Regular compatibility testing is split across GitHub Actions and nox:

  • GitHub Actions runs the workflow for each supported Python version.

  • nox runs the Django/DRF compatibility matrix.

The nox matrix validates lower and upper tracked combinations for Django and Django REST Framework, including cross-combinations:

  • min Django + min DRF

  • max Django + max DRF

  • min Django + max DRF

  • max Django + min DRF

This reduces the risk of regressions at supported boundaries while still keeping maintenance manageable. Additionally, the matrix validations can be run locally with the command poetry run nox.