Releases: launchdarkly/ruby-server-sdk
Releases · launchdarkly/ruby-server-sdk
5.5.4
[5.5.4] - 2019-03-29
Fixed:
- Fixed a missing
require
that could sometimes cause aNameError
to be thrown when starting the client, depending on what other gems were installed. This bug was introduced in version 5.5.3. (#129) - When an analytics event was generated for a feature flag because it is a prerequisite for another flag that was evaluated, the user data was being omitted from the event. (#128)
- If
track
oridentify
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). - Added a link from the SDK readme to the guide regarding the client initialization.
5.5.3
[5.5.3] - 2019-02-13
Changed:
- The SDK previously used the
faraday
andnet-http-persistent
gems for all HTTP requests other than streaming connections. Sincefaraday
lacks a stable version and has a known issue with character encoding, andnet-http-persistent
is no longer maintained, these have both been removed. This should not affect any SDK functionality.
Fixed:
- The SDK was not usable in Windows because of
net-http-persistent
. That gem has been removed. - When running in Windows, the event-processing thread threw a
RangeError
due to a difference in the Windows implementation ofconcurrent-ruby
. This has been fixed. - Windows incompatibilities were undetected before because we were not running a Windows CI job. We are now testing on Windows with Ruby 2.5.
5.5.2
[5.5.2] - 2019-01-18
Fixed:
- Like 5.5.1, this release contains only documentation fixes. Implementation classes that are not part of the supported API are now hidden from the generated documentation.
5.5.1
[5.5.1] - 2019-01-17
Fixed:
- Fixed several documentation comments that had the wrong parameter names. There are no other changes in this release; it's only to correct the documentation.
5.5.0
[5.5.0] - 2019-01-17
Added:
- It is now possible to use Consul or DynamoDB as a persistent feature store, similar to the existing Redis integration. See the
LaunchDarkly::Integrations::Consul
andLaunchDarkly::Integrations::DynamoDB
modules, and the reference guide Using a persistent feature store. - There is now a
LaunchDarkly::Integrations::Redis
module, which is the preferred method for creating a Redis feature store. - All of the database feature stores now support local caching not only for individual feature flag queries, but also for
all_flags_state
. - The
Config
propertydata_source
is the new name forupdate_processor
andupdate_processor_factory
.
Changed:
- The implementation of the SSE protocol for streaming has been moved into a separate gem,
ld-eventsource
. This has no effect on streaming functionality.
Fixed:
- Added or corrected a large number of documentation comments. All API classes and methods are now documented, and internal implementation details have been hidden from the documentation. You can view the latest documentation on RubyDoc.
- Fixed a problem in the Redis feature store that would only happen under unlikely circumstances: trying to evaluate a flag when the LaunchDarkly client had not yet been fully initialized and the store did not yet have data in it, and then trying again when the client was still not ready but the store did have data (presumably put there by another process). Previously, the second attempt would fail.
- In polling mode, the SDK did not correctly handle non-ASCII Unicode characters in feature flag data. (#90)
Deprecated:
RedisFeatureStore.new
. This implementation class may be changed or moved in the future; useLaunchDarkly::Integrations::Redis::new_feature_store
.Config.update_processor
andConfig.update_processor_factory
; useConfig.data_source
.
5.4.3
[5.4.3] - 2019-01-11
Changed:
- The SDK is now compatible with
net-http-persistent
3.x. (Thanks, CodingAnarchy!)
5.4.2
5.4.1
Note, version 5.4.0 was broken and has been removed.
[5.4.1] - 2018-11-05
Added:
- It is now possible to inject feature flags into the client from local JSON or YAML files, replacing the normal LaunchDarkly connection. This would typically be for testing purposes. See
file_data_source.rb
.
Fixed:
- When shutting down an
LDClient
, if in polling mode, the client was usingThread.raise
to make the polling thread stop sleeping.Thread.raise
can cause unpredictable behavior in a worker thread, so it is no longer used. - Fixed a
LoadError
infile_data_source.rb
, which was added in 5.4.0. (Thanks, kbarrette!)
5.3.0
[5.3.0] - 2018-10-24
Added:
- The
all_flags_state
method now accepts a new option,details_only_for_tracked_flags
, 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.
Fixed:
- JSON data from
all_flags_state
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.
5.2.0
[5.2.0] - 2018-08-29
Added:
- The new
LDClient
methodvariation_detail
allows you to evaluate a feature flag (using the same parameters as you would forvariation
) and receive more information about how the value was calculated. This information is returned in anEvaluationDetail
object, which 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:
- Evaluating a prerequisite feature flag did not produce an analytics event if the prerequisite flag was off.