6.6.0

[6.6.0] - 2018-11-14

Added:

• It is now possible to inject feature flags into the client from local JSON or YAML files, replacing the normal LaunchDarkly connection. This would typically be for testing purposes. See file_data_source.py.

6.5.0

[6.5.0] - 2018-10-17

Added:

• The all_flags_state method now accepts a new option, details_only_for_tracked_flags, which reduces the size of the JSON representation of the flag state by omitting some metadata. Specifically, it omits any data that is normally used for generating detailed evaluation events if a flag does not have event tracking or debugging turned on.

Changed:

• The SDK previously contained a copy of code from the expiringdict package. This has been changed to use the current version of that package from PyPi.

Fixed:

• JSON data from all_flags_state is now slightly smaller even if you do not use the new option described above, because it omits the flag property for event tracking unless that property is true.

6.4.2

[6.4.2] - 2018-09-21

Fixed:

• In polling mode, if the client received an HTTP error from LaunchDarkly, it stopped polling. This has been fixed so it only stops polling if the error is 401 (indicating an invalid SDK key).
• When using a Redis feature store, if the hgetall method returned an invalid result, all_flags and all_flags_state would throw an exception. Instead, all_flags will now return an empty dict, and all_flags_state will return a state object with no flags and valid==False. (Thanks, thieman!)

6.4.1

[6.4.1] - 2018-09-06

Fixed:

• In Python 3, if the Redis feature store encountered a Redis exception, it would crash on trying to log the message property of the exception, which does not exist in Python 3. This has been fixed. (Thanks, mattbriancon!)

6.4.0

[6.4.0] - 2018-08-29

Added:

• The new LDClient method variation_detail allows you to evaluate a feature flag (using the same parameters as you would for variation) and receive more information about how the value was calculated. This information is returned in an EvaluationDetail object, which contains both the result value and a "reason" object which will tell you, for instance, if the user was individually targeted for the flag or was matched by one of the flag's rules, or if the flag returned the default value due to an error.

Fixed:

• When evaluating a prerequisite feature flag, the analytics event for the evaluation did not include the result value if the prerequisite flag was off.

6.3.0

[6.3.0] - 2018-08-27

Added:

• The new LDClient method all_flags_state() should be used instead of all_flags() if you are passing flag data to the front end for use with the JavaScript SDK. It preserves some flag metadata that the front end requires in order to send analytics events correctly. Versions 2.5.0 and above of the JavaScript SDK are able to use this metadata, but the output of all_flags_state() will still work with older versions.
• The all_flags_state() method also allows you to select only client-side-enabled flags to pass to the front end, by using the option client_side_only=True.

Deprecated:

• LDClient.all_flags()

6.2.0

[6.2.0] - 2018-08-03

Changed:

• In streaming mode, each connection failure or unsuccessful reconnection attempt logs a message at ERROR level. Previously, this message included the amount of time before the next retry; since that interval is different for each attempt, that meant the ERROR-level messages were all unique, which could cause problems for monitors. This has been changed so the ERROR-level message is always the same, and is followed by an INFO-level message about the time delay. (Note that in order to suppress the default message, the LaunchDarkly client modifies the logger used by the backoff package; if you are using backoff for some other purpose and do want to see the default message, set logging.getLogger('backoff').propagate to True.) (#88)

6.1.1

[6.1.1] - 2018-06-19

Fixed:

• Removed an unused dependency on the CacheControl package.

6.1.0

[6.1.0] - 2018-06-18

Changed:

• The client now uses urllib3 for HTTP requests, rather than the requests package. This change was made because requests has a dependency on an LGPL-licensed package, and some of our customers cannot use LGPL code. The networking behavior of the client should be unchanged.
• The client now treats most HTTP 4xx errors as unrecoverable: that is, after receiving such an error, it will not make any more HTTP requests for the lifetime of the client instance, in effect taking the client offline. This is because such errors indicate either a configuration problem (invalid SDK key) or a bug in the client, which will not resolve without a restart or an upgrade. This does not apply if the error is 400, 408, 429, or any 5xx error.
• During initialization, if the client receives any of the unrecoverable errors described above, ldclient.get() will return immediately; previously it would continue waiting until a timeout. The is_initialized() method will return false in this case.

6.0.4

[6.0.4] - 2018-06-12

Fixed:

• Fixed a bug introduced in v6.0.3 that caused the user cache for analytics events to never be cleared, also causing an AttributeError to appear in the log.