Releases: launchdarkly/python-server-sdk
Releases · launchdarkly/python-server-sdk
6.8.1
[6.8.1] - 2019-01-31
Fixed:
- Fixed a packaging error that made the 6.8.0 release not installable. There are no other changes. The 6.8.0 release has been pulled from PyPI.
6.8.0
This release could not be installed due to a packaging error, and has been removed from PyPI.
[6.8.0] - 2019-01-31
Added:
- It is now possible to use Consul as a persistent feature store, similar to the existing Redis and DynamoDB integrations. See
Consul
inldclient.integrations
, and the reference guide for "Using a persistent feature store".
6.7.0
[6.7.0] - 2019-01-15
Added:
- It is now possible to use DynamoDB as a persistent feature store, similar to the existing Redis integration. See
DynamoDB
inldclient.integrations
, and the reference guide to "Using a persistent feature store". - The new class
CacheConfig
(inldclient.feature_store
) encapsulates all the parameters that control local caching in database feature stores. This takes the place of theexpiration
andcapacity
parameters that are in the deprecatedRedisFeatureStore
constructor; it can be used with DynamoDB and any other database integrations in the future, and if more caching options are added toCacheConfig
they will be automatically supported in all of the feature stores.
Deprecated:
- The
RedisFeatureStore
constructor inldclient.redis_feature_store
. The recommended way to create a Redis feature store now is to useRedis.new_feature_store
inldclient.integrations
.
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
andall_flags_state
would throw an exception. Instead,all_flags
will now return an empty dict, andall_flags_state
will return a state object with no flags andvalid==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
methodvariation_detail
allows you to evaluate a feature flag (using the same parameters as you would forvariation
) and receive more information about how the value was calculated. This information is returned in anEvaluationDetail
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
methodall_flags_state()
should be used instead ofall_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 ofall_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 optionclient_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 theERROR
-level messages were all unique, which could cause problems for monitors. This has been changed so theERROR
-level message is always the same, and is followed by anINFO
-level message about the time delay. (Note that in order to suppress the default message, the LaunchDarkly client modifies the logger used by thebackoff
package; if you are usingbackoff
for some other purpose and do want to see the default message, setlogging.getLogger('backoff').propagate
toTrue
.) (#88)