Skip to content

[3.5.4] - 2019-05-10

Changed:

  • Changed the package name from launchdarkly/launchdarkly-php to launchdarkly/server-sdk

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.

Assets 2

@LaunchDarklyCI LaunchDarklyCI released this Apr 26, 2019 · 1 commit to master since this release

[3.5.3] - 2019-04-26

Fixed:

  • 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 CONTRIBUTING.md.

Note on future releases

The LaunchDarkly SDK repositories are being renamed for consistency. This repository is now php-server-sdk rather than php-client.

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.

Assets 2

@LaunchDarklyCI LaunchDarklyCI released this Apr 12, 2019 · 5 commits to master since this release

[3.5.2] - 2019-04-11

Fixed:

  • In the 3.5.1 release, the VERSION constant was incorrectly still reporting the version as "3.5.0". The constant is now correct. There are no other changes in this release.
Assets 2

@eli-darkly eli-darkly released this Apr 3, 2019 · 8 commits to master since this release

[3.5.1] - 2019-04-03

Fixed:

  • 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.
  • If track or identify is 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).
Assets 2

@eli-darkly eli-darkly released this Apr 3, 2019 · 10 commits to master since this release

[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!)
Assets 2

@eli-darkly eli-darkly released this Sep 26, 2018 · 13 commits to master since this release

[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.
Assets 2

@eli-darkly eli-darkly released this Sep 4, 2018 · 14 commits to master since this release

[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.
Assets 2

@eli-darkly eli-darkly released this Aug 27, 2018 · 15 commits to master since this release

[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()
Assets 2

@eli-darkly eli-darkly released this Jul 16, 2018 · 16 commits to master since this release

[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.
Assets 2

@eli-darkly eli-darkly released this Jun 27, 2018 · 17 commits to master since this release

[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!)
Assets 2
You can’t perform that action at this time.