4.3.0

[4.3.0] - 2023-01-31

Added:

• Introduced support for an application_info config property which sets application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.

5.0.0

[5.0.0] - 2023-01-04

The latest version of this SDK supports LaunchDarkly's new custom contexts feature. Contexts are an evolution of a previously-existing concept, "users." Contexts let you create targeting rules for feature flags based on a variety of different information, including attributes pertaining to users, organizations, devices, and more. You can even combine contexts to create "multi-contexts."

This feature is only available to members of LaunchDarkly's Early Access Program (EAP). If you're in the EAP, you can use contexts by updating your SDK to the latest version and, if applicable, updating your Relay Proxy. Outdated SDK versions do not support contexts, and will cause unpredictable flag evaluation behavior.

If you are not in the EAP, only use single contexts of kind "user", or continue to use the user type if available. If you try to create contexts, the context will be sent to LaunchDarkly, but any data not related to the user object will be ignored.

For detailed information about this version, please refer to the list below. For information on how to upgrade from the previous version, please read the migration guide.

Added:

• The type LDContext defines the new "context" model. "Contexts" are a replacement for the earlier concept of "users"; they can be populated with attributes in more or less the same way as before, but they also support new behaviors. To learn more, read the documentation.
• For all SDK methods that took an LDUser parameter, the parameter type can now be either LDUser or LDContext. The SDK still supports LDUser for now, but LDContext is the preferred model and LDUser may be removed in a future version.

Changed (breaking changes from 4.x):

• It was previously allowable to set a user key to an empty string. In the new context model, the key is not allowed to be empty. Trying to use an empty key will cause evaluations to fail and return the default value.
• There is no longer such a thing as a secondary meta-attribute that affects percentage rollouts. If you set an attribute with that name in LDContext, it will simply be a custom attribute like any other.
• Component interface types like EventPublisher and FeatureRequester which applications are unlikely to reference directly (except when defining a custom component implementation) have been moved out of the main namespace into a new namespace, LaunchDarkly\Subsystems.

Changed (requirements/dependencies/build):

• The minimum PHP version is now 8.0.

Changed (behavioral changes):

• The SDK is now more strictly compliant with the LaunchDarkly specification for date and semantic version values. This means that some values that might have been accepted in the past, which other SDKs would not accept, are now correctly considered invalid. Please review the LaunchDarkly documentation on Using date/time and semantic version operators.
• Analytics event data now uses a new JSON schema due to differences between the context model and the old user model.

Fixed:

• Fixed a bug in the parsing of string values in feature flags and user attributes when they were referenced with date/time operators in a targeting rule. As described in LaunchDarkly documentation, such values must use the RFC3339 date/time format; the SDK was also accepting strings in other formats (for instance, ones that did not have a time or a time zone), which would cause undefined behavior inconsistent with evaluations done by other LaunchDarkly services. This fix ensures that all targeting rules that reference an invalid date/time value are a non-match, and does not affect how the SDK treats values that are in the correct format.
• The SDK was allowing numeric values to be treated as semantic versions in targeting rules. It now correctly only allows strings, as described in LaunchDarkly documentation.

Removed:

• Removed all types, fields, and methods that were deprecated as of the most recent 4.x release.
• Removed the secondary meta-attribute in LDUser and LDUserBuilder.
• The alias method no longer exists because alias events are not needed in the new context model.
• The inline_users_in_events option no longer exists because it is not relevant in the new context model.

4.2.4

[4.2.4] - 2022-10-07

Changed:

• CI builds now include a cross-platform test suite implemented in https://github.com/launchdarkly/sdk-test-harness. This is in addition to unit test coverage, and ensures consistent behavior across SDKs.

Fixed:

• Setting a base_uri or events_uri with a non-empty path, such as http://my-reverse-proxy-host/launchdarkly-requests, did not work.
• The object returned by allFlagsState(), when converted to JSON, had an incorrect format in the case where no flags exist.

4.2.3

[4.2.3] - 2022-09-07

Changed:

• Expanded upper version restriction on Monolog.

4.2.2

[4.2.2] - 2022-08-01

Fixed:

• The TestData class was incorrectly generating an error when updating a changed flag. (Thanks, aretenz!)

4.2.1

[4.2.1] - 2022-07-05

Changed:

• Expanded lower version restriction on Guzzle.

4.2.0

[4.2.0] - 2022-04-13

Added:

• Add support for psr/log v2 and v3.
• The LaunchDarkly\Integrations\TestData is a new way to inject feature flag data programmatically into the SDK for testing—either with fixed values for each flag, or with targets and/or rules that can return different values for different users. Unlike LaunchDarkly\Integrations\Files, this mechanism does not use any external resources, only the data that your test code has provided.

4.1.0

[4.1.0] - 2022-02-16

Added:

• The curl command used for publishing events will now honor the connect_timeout parameter.
• Publishing events on Windows will now use PowerShell and Invoke-WebRequest instead of curl.

Fixed:

• Numeric strings are no longer treated like numbers in equality checks.
• User attributes with values of 0 or false will no longer be filtered out of event payloads.
• When using allFlagsState to produce bootstrap data for the JavaScript SDK, the PHP SDK was not returning the correct metadata for evaluations that involved an experiment. As a result, the analytics events produced by the JavaScript SDK did not correctly reflect experimentation results.

4.0.0

[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:

• Added type declarations to all methods. These could result in a TypeError at runtime if you have been passing values of the wrong types to SDK methods (including passing a null value 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.

Changed:

• The minimum PHP version is now 7.3.
• Updated many dependencies to newer versions and/or more actively maintained packages.

Removed:

• 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 \LaunchDarkly namespace that were annotated as @internal and 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 \LaunchDarkly\Impl.

3.9.1

[3.9.1] - 2021-08-02

Fixed:

• The phpredis integration was ignoring the phpredis_client option for passing in a preconfigured Redis client. (Thanks, CameronHall!)