[4.0.0] - 2021-08-06
This major version release is for updating PHP compatibility, simplifying the SDK's dependencies, and removing deprecated names.
Except for the dependency changes described below which may require minor changes in your build, usage of the SDK has not changed in this release. For more details about changes that may be necessary, see the 3.x to 4.0 migration guide.
Dropping support for obsolete PHP versions makes it easier to maintain the SDK and keep its dependencies up to date. See LaunchDarkly's End of Life Policy regarding platform version support.
Simplifying dependencies by moving optional integration features into separate packages reduces the size of the SDK bundle, as well as reducing potential compatibility problems and vulnerabilities.
- Added type declarations to all methods. These could result in a
TypeErrorat runtime if you have been passing values of the wrong types to SDK methods (including passing a
nullvalue for a parameter that should not be null)-- although in most cases, this would have caused an error anyway at some point in the SDK code, just not such a clearly identifiable error. To detect type mistakes before runtime, you can use a static analysis tool such as Psalm.
- The minimum PHP version is now 7.3.
- Updated many dependencies to newer versions and/or more actively maintained packages.
- Removed the bundled Redis, DynamoDB, and Consul integrations. These are now provided as separate packages; see php-server-sdk-redis-predis, php-server-sdk-redis-phpredis, php-server-sdk-dynamodb, and php-server-sdk-consul.
- Removed all types and methods that were deprecated in the last 3.x version.
- Removed implementation types from the
\LaunchDarklynamespace that were annotated as
@internaland not documented, such as types that are part of the internal feature data model. These are not meant for use by application code, and are always subject to change. They have been moved into
[3.9.0] - 2021-06-21
- The SDK now supports the ability to control the proportion of traffic allocation to an experiment. This works in conjunction with a new platform feature now available to early access customers.
[3.7.6] - 2021-04-14
- When using
Files.featureRequester, if a data file did not contain valid JSON, the SDK would throw a PHP syntax error instead of the expected "File is not valid JSON" error. (Thanks, GuiEloiSantos!)
[3.7.3] - 2020-10-28
- When using the DynamoDB data store integration with a prefix string, the prefix was being prepended to keys with a slash separator (example:
my-prefix/features:my-flag-key). This was inconsistent with the colon separator that is used in the other server-side SDKs (example:
my-prefix:features:my-flag-key), making the PHP SDK unable to read flags that were put into the database by other SDKs or by the Relay Proxy, if a prefix was used. This has been fixed to be consistent with the other SDKs. (#138)
[3.7.2] - 2020-04-24
- The SDK could try to send analytics events even if
send_eventshad been set to false. This bug was introduced in the 3.6.0 release.
usestatement with the wrong namespace was causing Composer to print a deprecation warning. (Thanks, bfenton-smugmug!)
[3.7.1] - 2020-01-03
- Loosened the Monolog dependency constraint so that it will accept either a 1.x or a 2.x version. This should be compatible with all currently supported PHP versions; the SDK's use of Monolog does not rely on any features that are specific to 1.x. (Thanks, mrtus!)
- In rare circumstances (depending on the exact data in the flag configuration, the flag's salt value, and the user properties), a percentage rollout could fail and return a default value, logging the error "Data inconsistency in feature flag ... variation/rollout object with no variation or rollout". This would happen if the user's hashed value fell exactly at the end of the last "bucket" (the last variation defined in the rollout). This has been fixed so that the user will get the last variation.