3.5.0

[3.5.0] - 2019-01-30

Added:

• It is now possible to use Consul or DynamoDB as a data store with ld-relay, similar to the existing Redis integration. See LaunchDarkly\Integrations\Consul and LaunchDarkly\Integrations\DynamoDb, and the reference guide Using a persistent feature store.
• When using the Redis integration, you can specify a Redis connection timeout different from the default of 5 seconds by setting the option redis_timeout to the desired number of seconds. (Thanks, jjozefowicz!)
• It is now possible to inject feature flags into the client from local JSON files, replacing the normal LaunchDarkly connection. This would typically be for testing purposes. See LaunchDarkly\Integrations\Files.
• The allFlagsState method now accepts a new option, detailsOnlyForTrackedFlags, 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 feature_requester and event_publisher configuration options now work differently: you can still set them to an instance of an implementation object, but you can also set them to a class or a class name (i.e. the same as the feature_requester_class option), or a factory function. Therefore, the _class versions of these options are no longer necessary. However, the old semantics still work, so you can for instance set event_publisher_class to "LaunchDarkly\GuzzleEventPublisher", even though the new preferred way is to set event_publisher to LaunchDarkly\Integrations\Guzzle::featureRequester().

Fixed:

• JSON data from allFlagsState 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.
• The $_anonymous property of the LDUser class was showing up as public rather than protected. (Thanks, dstockto!)

3.4.1

[3.4.1] - 2018-09-25

Fixed:

• Improved the performance of allFlags/allFlagsState by not making redundant individual requests for prerequisite flags, when a flag is being evaluated that has prerequisites. Instead it will reuse the same flag data that it already obtained from LaunchDarkly in the "get all the flags" request.

3.4.0

[3.4.0] - 2018-09-04

Added:

• The new LDClient method variationDetail 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 object that 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.

3.3.0

[3.3.0] - 2018-08-27

Added:

• The new LDClient method allFlagsState() should be used instead of allFlags() 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 allFlagsState() will still work with older versions.
• The allFlagsState() method also allows you to select only client-side-enabled flags to pass to the front end, by using the option clientSideOnly => true.

Deprecated:

• LDClient.allFlags()

3.2.1

[3.2.1] - 2018-07-16

Fixed:

• The LDClient::VERSION constant has been fixed to report the current version. In the previous release, it was still set to 3.1.0.

3.2.0

[3.2.0] - 2018-06-26

Changed:

• The client now treats most HTTP 4xx errors as unrecoverable: that is, after receiving such an error, it will take the client offline (for the lifetime of the client instance, which in most PHP applications is just the current request-response cycle). This is because such errors indicate either a configuration problem (invalid SDK key) or a bug, which is not likely to resolve without a restart or an upgrade. This does not apply if the error is 400, 408, 429, or any 5xx error.

Fixed:

• Made various changes to project settings to improve the IDE experience and the build; enforced PSR-2 coding style. (Thanks, localheinz!)

3.1.0

[3.1.0] - 2018-04-30

Added

• Analytics events for feature evaluations now have a variation property (the variation index) as well as value. This will allow for better performance in future versions of ld-relay when it is used with the PHP client.

Fixed

• Fixed a bug that made segment-based rules always fall through when using LDDFeatureRequester.

3.0.0

Added

• Support for a new LaunchDarkly feature: reusable user segments.

2.5.0

[2.5.0] - 2018-02-13

Added

• Adds support for a future LaunchDarkly feature, coming soon: semantic version user attributes.

2.4.0

[2.4.0] - 2018-01-04

Added

• Support for private user attributes.

Changed

• Stop retrying HTTP requests if the API key has been invalidated.
• User bucketing supports integer attributes. Thanks @mlund01!
• Source code complies with the PSR-2 standard. Thanks @valerianpereira!

Fixed

• The PSR-4 autoloading specification is now correct. Thanks @jenssegers!