Release Notes¶
Pending¶
What's new?¶
5.0.13¶
What's new?¶
- Modernize code for Python 3.6+ (thanks @adamchainz!)
- Run linters with Python 3.11 (thanks @adamchainz!)
- Format with Black 23 (thanks @adamchainz!)
- Added Django 4.2 support (thanks @adamchainz!).
Removals¶
- Removed Python 3.6 support (thanks @michael-k!).
Bug fixes¶
- Removed errant print statement (thanks @Natim!).
5.0.12¶
What's new?¶
- Added Django 4.1 support (thanks @adamchainz!).
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 inflagged_path()
URL patterns (#100)
5.0.9¶
What's new?¶
- Fixed a
DeprecationWarning
on Jinja 3+. - Fixed an
AttributeError
onAnonymousUser
in the user condition (thanks @edomora97!)
5.0.8¶
What's new?¶
- Prevent
RemovedInDjango41Warning
aboutdefault_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?¶
- Added
enable_flag
anddisable_flag
functions. - Added
enable_flag
anddisable_flag
management commands.
5.0.2¶
What's new?¶
- Added defaults for
FlaggedViewMixin
'skwargs
(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 nowFalse
by default to cut down on potentially unwanted noise (@darakian).
4.2.3¶
What's new?¶
- Removed the word "optional" to describe non-required conditions in the Flag Conditions Debug Toolbar panel.
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?¶
- Made the language around optional boolean conditions with required conditions clearer in the Flag Conditions Debug Toolbar panel
4.2.0¶
What's new?¶
- Added optional Django Debug Toolbar panels to list all flag conditions and to report flag checks for a request.
- Added flag state check logging and
FLAGS_STATE_LOGGING
setting to enable it. - Modified flag state checking to raise an
AppRegistryNotReady
if an attempt to check flag state is made before the app registry is ready. - Modified flag view decorators to warn if a fallback view do not take the same arguments as the flag view.
4.1.2¶
What's new?¶
- Added support for Django 2.2 and Python 3.7 (Chris Adams).
4.1.1¶
What's new?¶
boolean
andanonymous
conditions now accept multiple possible string representations of truth as their values.parameter
conditions now accept possible parameter values.
4.1¶
What's new?¶
- Added the option to specifiy required conditions that must always be met.
- Deprecated support for using a single dictionary to hold key/values of conditions for a settings-based feature flag. Support will be removed in Django-Flags 5.0. Use a list of dictionaries or tuples instead.
- Added a
before date
condition that is met whenever the current date is before the expected date.
4.0.3¶
What's new?¶
- The system check introduced in 4.0.2 will no longer raise a
ProgrammingError
or anOperationalError
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 FalsyNone
instead of raising aTypeError
when a configured condition has no function registered.
4.0¶
What's new?¶
- The template functions
flag_enabled
andflag_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
andflag_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.