4.0.0

[4.0.0] - 2018-05-10

Changed:

• To reduce the network bandwidth used for analytics events, feature request events are now sent as counters rather than individual events, and user details are now sent only at intervals rather than in each event. These behaviors can be modified through the LaunchDarkly UI and with the new configuration option inlineUsersInEvents. For more details, see Analytics Data Stream Reference.
• When sending analytics events, if there is a connection error or an HTTP 5xx response, the client will try to send the events again one more time after a one-second delay.
• The LdClient class is now final.

Added:

• New methods on LDConfig.Builder (updateProcessorFactory, featureStoreFactory, eventProcessorFactory) allow you to specify different implementations of each of the main client subcomponents (receiving feature state, storing feature state, and sending analytics events) for testing or for any other purpose. The Components class provides factories for all built-in implementations of these.

Deprecated:

• The featureStore configuration method is deprecated, replaced by the new factory-based mechanism described above.

3.0.3

[3.0.3] - 2018-03-26

Fixed

• In the Redis feature store, fixed a synchronization problem that could cause a feature flag update to be missed if several of them happened in rapid succession.
• Fixed a bug that would cause a NullPointerException when trying to evaluate a flag rule that contained an unknown operator type. This could happen if you started using some recently added feature flag functionality in the LaunchDarkly application but had not yet upgraded the SDK to a version that supports that feature. In this case, it should now simply treat that rule as a non-match.

Changed

• The log message "Attempted to update ... with a version that is the same or older" has been downgraded from WARN level to DEBUG. It can happen frequently in normal operation when the client is in streaming mode, and is not a cause for concern.

3.0.2

[3.0.2] - 2018-03-01

Fixed

• Improved performance when evaluating flags with custom attributes, by avoiding an unnecessary caught exception (thanks, rbalamohan).

2.6.1

[2.6.1] - 2018-03-01

Fixed

• Improved performance when evaluating flags with custom attributes, by avoiding an unnecessary caught exception (thanks, rbalamohan).

3.0.1

[3.0.1] - 2018-02-22

Added

• Support for a new LaunchDarkly feature: reusable user segments.

Changed

• The FeatureStore interface has been changed to support user segment data as well as feature flags. Existing code that uses InMemoryFeatureStore or RedisFeatureStore should work as before, but custom feature store implementations will need to be updated.
• Removed deprecated methods.

3.0.0

This release was broken and should not be used.

2.6.0

[2.6.0] - 2018-02-12

Added

• Adds support for a future LaunchDarkly feature, coming soon: semantic version user attributes.

Changed

• It is now possible to compute rollouts based on an integer attribute of a user, not just a string attribute.

2.5.1

[2.5.1] - 2018-01-31

Changed

• All threads created by the client are now daemon threads.
• Fixed a bug that could result in a previously deleted feature flag appearing to be available again.
• Reduced the logging level for use of an unknown feature flag from WARN to INFO.

2.5.0

[2.5.0] - 2018-01-08

Added

• Support for specifying private user attributes in order to prevent user attributes from being sent in analytics events back to LaunchDarkly. See the allAttributesPrivate and privateAttributeNames methods on LDConfig.Builder as well as the privateX methods on LDUser.Builder.

2.4.0

[2.4.0] - 2017-12-20

Changed

• Added an option to disable sending analytics events
• No longer attempt to reconnect if a 401 response is received (this would indicate an invalid SDK key, so retrying won't help)
• Simplified logic to detect dropped stream connections
• Increased default polling interval to 30s
• Use flag data in redis before stream connection is established, if possible (See #107)
• Avoid creating HTTP cache when streaming mode is enabled (as it won't be useful). This makes it possible to use the SDK in Google App Engine and other environments with no mutable disk access.