4.7.2

[4.7.2] - 2019-04-25

Changed:

• The default value for the Config property Capacity (maximum number of events that can be stored at once) is now 10000, consistent with the other SDKs, rather than 1000.

Fixed:

• If Track or Identify is called without a user, the SDK now will not send an analytics event to LaunchDarkly (since it would not be processed without a user).
• The size of the SDK codebase has been reduced considerably by eliminating unnecessary files from vendor.

Note on future releases:

The LaunchDarkly SDK repositories are being renamed for consistency. All future releases of the Go SDK will use the name go-server-sdk rather than go-client. The import path will change to:

"gopkg.in/launchdarkly/go-server-sdk.v4"

Since Go uses the repository name as part of the import path, to avoid breaking existing code, we will retain the existing go-client repository as well. However, it will not be updated after this release.

4.7.1

[4.7.1] - 2019-01-09

Fixed:

• Fixed a potential race condition in the DynamoDB and Consul feature store integrations where it might be possible to see a feature flag that depended on a prerequisite flag (or on a user segment) before the latter had been written to the store.

4.7.0

[4.7.0] - 2018-12-18

Added:

• The new configuration option EventsEndpointUri allows the entire URI for event posting to be customized, not just the base URI. This is used by the LaunchDarkly Relay Proxy and will not normally be needed by developers.
• Configuration options that did not have documentation comments are now documented.

4.6.1

[4.6.1] - 2018-11-26

Fixed:

• Fixed a bug in the DynamoDB feature store that caused read operations to fail sometimes if the lddynamodb.Prefix option was used.

4.6.0

[4.6.0] - 2018-11-16

Added:

• With the DynamoDB feature store, it is now possible to specify a prefix string for the database keys, so that multiple SDK clients can share the same DynamoDB table without interfering with each other's data as long as they use different prefixes. This feature was already available for Redis and Consul.

4.5.1

[4.5.1] - 2018-11-15

Fixed:

• Previously, the DynamoDB feature store implementation could fail if a feature flag contained an empty string in any property, since DynamoDB does not allow empty strings. This has been fixed by storing a JSON representation of the entire feature flag, rather than individual properties. The same implementation will be used by all other LaunchDarkly SDKs that provide a DynamoDB integration, so they will be interoperable.

4.5.0

[4.5.0] - 2018-11-14

Added:

• It is now possible to use DynamoDB or Consul as a persistent feature store, similar to the existing Redis integration. See the ldconsul and lddynamodb subpackages, and the reference guide to "Using a persistent feature store".

4.4.0

[4.4.0] - 2018-10-30

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 the ldfiledata and ldfilewatch subpackages.

• The AllFlagsState method now accepts a new option, DetailsOnlyForTrackedFlags, 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 AllFlagsState is now slightly smaller even if you do not use the new option described above, because it completely omits the flag property for event tracking unless that property is true.

• Evaluating a prerequisite feature flag did not produce an analytics event if the prerequisite flag was off.

4.3.0

[4.3.0] - 2018-08-27

Added:

• The new LDClient method AllFlagsState() should be used instead of AllFlags() if 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. Versions 2.5.0 and above of the JavaScript SDK are able to use this metadata, but the output of AllFlagsState() will still work with older versions.
• The AllFlagsState() method also allows you to select only client-side-enabled flags to pass to the front end, by using the option ClientSideOnly.
• The new LDClient methods BoolVariationDetail, IntVariationDetail, Float64VariationDetail, StringVariationDetail, and JsonVariationDetail allow you to evaluate a feature flag (using the same parameters as you would for BoolVariation, etc.) and receive more information about how the value was calculated. This information is returned in an EvaluationDetail object, which contains both the result value and an EvaluationReason 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.

Deprecated:

• LDClient.AllFlags(), EvalResult, FeatureFlag.Evaluate, FeatureFlag.EvaluateExplain

4.2.2

[4.2.2] - 2018-08-03

Fixed:

• Fixed a bug that caused a panic if an I/O error occurred while reading the response body for a polling request.
• Fixed a bug that caused a panic if a prerequisite feature flag evaluated to a non-scalar value (array or map/hash).
• Receiving an HTTP 400 error from LaunchDarkly should not make the client give up on sending any more requests to LaunchDarkly (unlike a 401 or 403).