Releases: launchdarkly/erlang-server-sdk
2.0.5
[2.0.5] - 2023-06-12
Changed:
- Upgraded
yamerlto version0.10.0.
2.0.4
[2.0.4] - 2023-06-05
Fixed:
- Remove error log message associated with debugging redis initialization state.
2.0.3
[2.0.3] - 2023-05-30
Fixed:
- Add missing
boolean()type to theldclient_context:attribute_value()definition.
2.0.2
[2.0.2] - 2023-05-26
Fixed:
- Fixed an issue that would prevent using values from redis for
variationorall_flags_statecalls before client initialization was complete. After this change if the erlang SDK is using an initialized redis prefix, then it will be able to evaluate against that store before initialization is complete. Note that the SDK did not previously store the$initedkey used when detecting that a store is initialized, so the store will need updated by this SDK version (or newer) at least once before it would be considered initialized.
2.0.1
[2.0.1] - 2023-05-04
Fixed:
- Fixed an issue where invalid contexts would generate events resulting in a crash in the event server.
2.0.0
[2.0.0] - 2023-02-22
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:
- Added a new module,
ldclient_context, which defines the new "context" model. - All SDK methods that took an
ldclient_user:user()now accept anldclient_context:context()as well. - Added
ldclient_flagbuilder:if_match/4,ldclient_flagbuilder:if_not_match/4,ldclient_flagbuilder:and_match/4, andldclient_flagbuilder:and_not_match/4which allow creating rules targeting specific context kinds usingldclient_testdata.
Changed (breaking changes from 1.x):
- The secondary meta-attribute, which previously affected percentage rollouts, no longer exists. If you set an attribute with that name in
ldclient_context:context(), it will simply be a custom attribute like any other. - Evaluations now treat the anonymous attribute as a simple boolean, with no distinction between a false state and an undefined state.
- The
binary()values inprivate_attributesin the configuration map now represent attribute references. If an attribute name had started with a/, then that will need to be escaped. For instance/myAttributewould now reference an attribute namedmyAttributenot an attribute named/myAttribute. The attribute reference would need to be updated to the escaped form/~1myAttribute. ldclient_flagbuilder:variation_for_all_usershas been replaced withldclient_flagbuilder:variation_for_alland now applies to contexts.ldclient_flagbuilder:variation_for_userhas been replaced withldclient_flagbuilder:variation_for_contextand requires a context kind to be provided.user_keys_capacityhas been replaced withcontext_keys_capacityin the option configuration map.
Changed (behavioral changes):
- The SDK can now evaluate segments that have rules referencing other segments.
- Analytics event data now uses a new JSON schema due to differences between the context model and the old user model.
Removed:
- Removed the
secondarymeta-attribute inldclient_user:user(). - The
ldclient:aliasmethod no longer exists because alias events are not needed in the new context model. - The
inline_users_in_eventsoption no longer exists because it is not relevant in the new context model.
1.6.0
[1.6.0] - 2023-01-30
Added:
applicationoption, for configuration of application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.
ldclient:start_instance("sdk-key", #{
application => #{
id => <<"my-app-id">>,
version => <<"my-app-version">>
}
})
- Added support for using server time, from response headers, when determining if debug events should be sent.
Changed:
- Updated jitter/backoff implementation to be consistent with other SDK implementations.
- Upgraded
lruto version2.4.0. - Upgrade
certifito version2.10.0. - Removed dependency on
backoff.
Fixed:
- Fixed an issue where the SDK did not handle deleted flags/segments correctly in combination with evaluation of all flags.
- Allow for track data to be
null.
1.5.0
[1.5.0] - 2022-06-23
Changed:
- Updated
certifito 2.9.0. - Updated
shotgunto 0.5.3. This should obviate the need to overrideshotguninmix.exsfor Elixir projects.
Fixed:
- Updated URI parsing to work with OTP 25. Removing the usage of
http_uri:parseand replacing it withuri_string:parse.
1.4.0
[1.4.0] - 2022-04-20
Added:
ldclient:all_flags_state/3to be used instead ofldclient:all_flags_state/1 or /2if 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. It does NOT yet support selecting client-side-enabled flags.ldclient_testdatais 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 the file data source, this mechanism does not use any external resources, only the data that your test code has provided.- Support for the SDK test harness.
Fixed:
- An issue with handling
firstNameandlastNamein rules. The SDK usesfirst_nameandlast_nameatoms for these fields and there was an issue with when the attribute names were converted. Now name conversion for attributes are done after evaluation and processing of private attributes. ldclient:trackandldclient:tack_metricwill not allow for types other thanmap()to be used fordata.- The SDK was sending identify events for users with an empty key when it should not.
- The SDK would send duplicate events for a user which had been identified and then was noticed by a feature evaluation. Now the event will be de-duplicated correctly within the LRU cache timeout.
- Rule matches against dates in the user object, which could not be parsed, would cause evaluation to fail and return the default value. Now they will correctly result in the rule not matching instead.
- The configuration was not trimming trailing
/from URLs.
Changed:
- Event fields which contained false or null will not generally be omitted from events for compactness.
- Clarifications to documentation.
1.3.2
[1.3.2] - 2021-12-30
Fixed:
- The file
file_auto_updatefeature was not working correctly. If the flag files did not contain any changes between polling intervals, then the file system watcher would crash. (Thanks, matt-glover!)