Release Notes

5.1.0

What's new?

  • Added support for Python 3.13, removed support for Python < 3.10

5.0.14

What's new?

  • Updated packaging to pyproject.toml and linting/formatting to ruff
  • Added Django 5.0 support (thanks @adamchainz!)
  • Added Django 5.2 support (thanks @sergei-maertens!)

Bug fixes

  • Fixed parameter condition example in docs (thanks @andy-isoc!)

5.0.13

What's new?

Removals

  • Removed Python 3.6 support (thanks @michael-k!).

Bug fixes

  • Removed errant print statement (thanks @Natim!).

5.0.12

What's new?

5.0.11

What's new?

  • Added changelog and documentation links to the package on PyPI (thanks @adamchainz!)

5.0.10

What's new?

  • Fixed an issue with resolving include()s in flagged_path() URL patterns (#100)

5.0.9

What's new?

  • Fixed a DeprecationWarning on Jinja 3+.
  • Fixed an AttributeError on AnonymousUser in the user condition (thanks @edomora97!)

5.0.8

What's new?

  • Prevent RemovedInDjango41Warning about default_app_config for Django 3.2+ (thanks @adamchainz!)

5.0.7

What's new?

  • Update Django 4 pin to allow versions under 4.1

5.0.6

What's new?

  • Added Django 4.0 support (thanks @gregtap!)

5.0.5

What's new?

  • Added Django 3.2 support (thanks @dduong42!)

5.0.4

What's new?

  • Fixed the "path matches" condition validator to allow any valid regular expression.

5.0.3

What's new?

5.0.2

What's new?

  • Added defaults for FlaggedViewMixin's kwargs (by @jackton1)

5.0.1

What's new?

  • Added Django 3.1 support

5.0.0

What's new?

  • Added Django 3.0 support
  • Added validator support to ensure that the values that flag conditions test against are valid.

Deprecations

  • Deprecated the optional flags.middleware.FlagConditionsMiddleware in favor of always lazily caching flags on the request object.

Removals

  • Django Flags 4.1 deprecated support for using a single dictionary to hold key/values of conditions for a settings-based feature flag, and this has been removed. Use a list of dictionaries or tuples instead.
  • Removed support for Django 1.11.

4.2.4

What's new?

  • FLAGS_STATE_LOGGING is now False by default to cut down on potentially unwanted noise (@darakian).

4.2.3

What's new?

4.2.2

What's new?

  • Fixed a bug where if a flag was defined in multiple sources the conditions defined in subsequent sources would not be evaluated. This means (with the default sources) if a flag is defined in Django settings and has conditions defined the database, only the settings conditions would be evaluated.

4.2.1

What's new?

4.2.0

What's new?

4.1.2

What's new?

4.1.1

What's new?

4.1

What's new?

4.0.3

What's new?

  • The system check introduced in 4.0.2 will no longer raise a ProgrammingError or an OperationalError when run pre-migration.

4.0.2

What's new?

  • Logging of non-existent conditions is now a Django system check.

4.0.1

What's new?

  • condition.check() returns a Falsy None instead of raising a TypeError when a configured condition has no function registered.

4.0

What's new?

  • The template functions flag_enabled and flag_disabled in both Django and Jinja2 templates now support taking keyword arguments that could be used by custom conditions.
  • Jinja2 template functions are now available via a Jinja2 extension that can be included in settings.py.
  • The optional flags.middleware.FlagConditionsMiddleware has been added to ensure that all feature flag checks throughout single request cycle use the same flag conditions.
  • Support for specifying the source of feature flags in settings.py has been added to allow further customization and the potential to limit flags to settings or database-only.
  • The "user" condition now supports custom user models. (@callorico)

Upgrading

Django-Flags 4.0 introduces backwards-incompatible changes for users of Jinja2 templates.

Previously Django-Flags provided flags.template_functions.flag_enabled and flags.template_functions.flag_disabled functions that had to be registered in the Jinja2 environment downstream. The Django-Flags documentation recommended doing so in jinja2.Environment.globals.update(). flags.template_functions has been removed in Django-Flags 4.0.

Jinja2 function registration is now handled by a flags.jinja2tags.flags Jinja2 extension. To use Django-Flags 4.0 with Jinja2 templates, the TEMPLATES setting in settings.py should to be modified to include the extension:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.jinja2.Jinja2',
        ...
        'OPTIONS': {
            'extensions': [
                ...
                'flags.jinja2tags.flags',  # add this line to your existing settings
                ...
            ],
        }
    },
]

3.0.2

What's new?

  • Requests are now optional the flag_enabled and flag_disabled template tags.
  • Flag state form conditions are now bound when the form is created to ensure all custom conditions are available on the form. (@callorico)

3.0.1

What's new?

  • Django 2.1 is now supported.

3.0

Django-Flags is a fork of the Django-only components of the Wagtail-Flags feature flag library. This is the initial release.