Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 36 million developers.Sign up
[3.5.4] - 2019-05-10
- Changed the package name from
There are no other changes in this release. Substituting
launchdarkly/launchdarkly-php version 3.5.3 with
launchdarkly/server-sdk version 3.5.4 will not affect functionality.
[3.5.3] - 2019-04-26
- Segment rollout calculations did not work correctly if the rollout was based on a user attribute other than
key; all users would end up in the same bucket. (Thanks, m6w6!)
- Running the SDK unit tests is now simpler, as the database integrations can be skipped. See
Note on future releases
The LaunchDarkly SDK repositories are being renamed for consistency. This repository is now
php-server-sdk rather than
The package name will also change. In the 3.5.3 release, it is still
launchdarkly/launchdarkly-php; in all future releases, it will be
launchdarkly/server-sdk. No further updates to the
launchdarkly/launchdarkly-php package will be published after this release.
[3.5.2] - 2019-04-11
- In the 3.5.1 release, the
VERSIONconstant was incorrectly still reporting the version as "3.5.0". The constant is now correct. There are no other changes in this release.
[3.5.1] - 2019-04-03
- Setting user attributes to non-string values when a string was expected would cause analytics events not to be processed. The SDK will now convert attribute values to strings as needed.
identifyis called without a user, the SDK now logs a warning, and does not send an analytics event to LaunchDarkly (since it would not be processed without a user).
[3.5.0] - 2019-01-30
- 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\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_timeoutto 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
allFlagsStatemethod 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.
event_publisherconfiguration 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_classoption), or a factory function. Therefore, the
_classversions of these options are no longer necessary. However, the old semantics still work, so you can for instance set
"LaunchDarkly\GuzzleEventPublisher", even though the new preferred way is to set
- JSON data from
allFlagsStateis 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.
$_anonymousproperty of the
LDUserclass was showing up as public rather than protected. (Thanks, dstockto!)
[3.4.1] - 2018-09-25
- Improved the performance of
allFlagsStateby 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] - 2018-09-04
- The new
variationDetailallows 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.
- 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] - 2018-08-27
- The new
allFlagsState()should be used instead of
allFlagsState()will still work with older versions.
allFlagsState()method also allows you to select only client-side-enabled flags to pass to the front end, by using the option
clientSideOnly => true.
[3.2.1] - 2018-07-16
LDClient::VERSIONconstant has been fixed to report the current version. In the previous release, it was still set to 3.1.0.
[3.2.0] - 2018-06-26
- 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.
- Made various changes to project settings to improve the IDE experience and the build; enforced PSR-2 coding style. (Thanks, localheinz!)