Skip to content

Releases: launchdarkly/ruby-server-sdk

7.0.2

27 Jan 21:34
Compare
Choose a tag to compare

[7.0.2] - 2023-01-27

Fixed:

  • Fixed JSON serialization error on internal models.

7.0.1

19 Jan 21:26
Compare
Choose a tag to compare

[7.0.1] - 2023-01-19

Changed:

  • Improved logging of feature flag data validation errors so that they are logged once at the time the SDK receives the data, rather than during each evaluation of the flag.

Fixed:

  • Removed a misleading error message about a missing attribute that was being logged when a flag rule used the "is in segment" operator.

7.0.0

30 Dec 20:15
Compare
Choose a tag to compare

[7.0.0] - 2022-12-30

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 LaunchDarkly::LDContext defines the new context model.
  • All SDK methods that took a hash representing the user now also accept an LDContext.

Changed (breaking changes from 6.x):

  • The secondary attribute which existed in the user hash is no longer a supported feature. If you set an attribute with that name in LDContext, it will simply be a custom attribute like any other.
  • Analytics event data now uses a new JSON schema due to differences between the context model and the old user model.

Changed (requirements/dependencies/build):

  • The minimum language version is now Ruby 2.7, or jRuby 9.4.

Changed (behavioral changes):

  • Several optimizations within the flag evaluation logic have improved the performance of evaluations. For instance, target lists are now stored internally as sets for faster matching.

Removed:

  • Removed support for the secondary meta-attribute in the user hash.
  • 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.
  • Removed all types and options that were deprecated as of the most recent 6.x release.

Deprecated:

  • Config options user_keys_capacity and user_keys_flush_interval are being replaced with context_keys_capacity and context_keys_flush_interval.
  • Config constants default_user_keys_capacity and default_user_keys_flush_interval are being replaced with default_context_keys_capacity and default_context_keys_flush_interval.

6.4.0

07 Sep 23:36
Compare
Choose a tag to compare

[6.4.0] - 2022-09-07

Added:

  • New Config property application_info, for configuration of application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.

Changed:

  • The SDK now produces fewer short-lived objects as a side effect of flag evaluations, causing less work for the garbage collector in applications that evaluate flags very frequently. This change applies to all flag evaluations, regardless of whether analytics events are enabled.

6.3.4

30 Jun 00:38
Compare
Choose a tag to compare

[6.3.4] - 2022-06-29

Changed:

  • Miscellaneous improvements to memory usage in analytics event processing: the SDK now allocates somewhat fewer short-lived objects when computing the analytics data for flag evaluations. This does not affect baseline memory usage by the SDK, but could somewhat reduce the need for garbage collection over an application's lifetime.
  • The decrease in allocation of short-lived objects is much more significant if analytics events are completely disabled. Previously, the SDK created and then discarded event-related objects in this case even though they were not being used.

6.3.3

15 Jun 23:43
Compare
Choose a tag to compare

[6.3.3] - 2022-06-15

Fixed:

  • Improved efficiency of SSE parsing to reduce transient memory/CPU usage spikes when receiving flag/segment data for a large LaunchDarkly environment. (Thanks, sq-square!)

6.3.2

18 Mar 21:13
Compare
Choose a tag to compare

[6.3.2] - 2022-03-18

Added:

  • Add initial_reconnect_delay option to config which controls the initial delay for reconnecting the streaming connection.
  • CI builds now include a cross-platform test suite implemented in https://github.com/launchdarkly/sdk-test-harness. This covers many test cases that are also implemented in unit tests, but may be extended in the future to ensure consistent behavior across SDKs in other areas.

Fixed:

  • The HTTP_PROXY/HTTPS_PROXY environment variables are now correctly applied for all requests to LaunchDarkly. Previously, this setting worked for streaming flag requests, but did not work for analytics event delivery (or flag polling), causing the latter to be attempted without using the proxy.
  • Rules targeting secondary attribute on user will now reference the correct value.
  • all_flags_state will return invalid flag state if the store hasn't initialized properly.
  • When using all_flags_state to produce bootstrap data for the JavaScript SDK, the Ruby 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.
  • The info level message logged when using DynamoDB now correctly identifies the feature store description. (#195)

Changed:

  • Providing a configuration hash when instantiating a persistent store is now optional.

6.3.1

31 Dec 22:07
Compare
Choose a tag to compare

[6.3.1] - 2021-12-31

Fixed:

  • Fixed a bug that could cause a streaming connection to fail intermittently if the feature flag data contained UTF-8 characters outside of the ASCII character set. This would happen if a multi-byte character happened to be split across two successive reads from the stream, so the chances of it happening varied according to how often international characters appeared in the data and how much buffering of reads was done by the OS.
  • In JRuby only, stream reconnections would fail if the application explicitly set the initial reconnect delay to zero.

6.3.0

09 Dec 23:39
Compare
Choose a tag to compare

[6.3.0] - 2021-12-09

Added:

  • The SDK now supports evaluation of Big Segments. See: https://docs.launchdarkly.com/home/users/big-segments
  • 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 FileData, this mechanism does not use any external resources, only the data that your test code has provided.

Changed:

  • To use the file data source feature, the preferred entry point is now LaunchDarkly::Integrations::FileData.data_source rather than LaunchDarkly::FileDataSource.factory. This makes the Ruby SDK more consistent with other SDKs, grouping together all of the optional "connecting the SDK to something else" features under Integrations, and using the method name data_source for consistency with the Config property that will receive the object.

Deprecated:

  • LaunchDarkly::FileDataSource (see above).

6.2.5

12 Oct 23:21
Compare
Choose a tag to compare

[6.2.5] - 2021-10-12

Fixed:

  • Fixed a bug that caused unnecessarily heavy CPU usage when receiving very large sets of flag data from LaunchDarkly.
  • Improved the speed of making the initial streaming connection to LaunchDarkly. The delay that happens before reconnecting after a connection failure was mistakenly being applied before the first connection.