v6.0.3

[6.0.3] - 2023-03-01

Changed:

• Bumped go-sdk-events to v2.0.1
• Bumped go-server-sdk-evaluation to v2.0.2

Fixed:

• Bumped go-sdk-common to v3.0.1. This fixes a bug within the easyJSON unmarshaller when an unexpected privateAttributes or redactedAttributes was encountered in a Context _meta attribute.

v6.0.2

[6.0.2] - 2023-02-27

Changed:

• Bumped golang/x/crypto and golang/x/sys to v0.1.0

v6.0.1

[6.0.1] - 2023-01-17

Fixed:

• If the application configured custom base URIs that did not have a valid URI syntax, the SDK could panic at startup time. It will now simply log an error and be unable to connect to LaunchDarkly.
• Fixed shared test logic that is used by the database integration packages.

v5.10.1

[5.10.1] - 2023-01-17

Fixed:

• If the application configured custom base URIs that did not have a valid URI syntax, the SDK could panic at startup time. It will now simply log an error and be unable to connect to LaunchDarkly.
• Fixed shared test logic that is used by the database integration packages.

v6.0.0

[6.0.0] - 2022-12-07

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:

• In go-sdk-common, the new package ldcontext with the types Context and Kind defines the new context model.
• The ldtestdata flag builder methods have been extended to support now context-related options, such as matching a key for a specific context type other than "user".
• LDClient.FlushAndWait() is a synchronous version of Flush().

Changed (breaking changes from 5.x):

• The SDK packages now use regular Go module import paths rather than gopkg.in paths: gopkg.in/launchdarkly/go-server-sdk.v5 is replaced by github.com/launchdarkly/go-server-sdk/v6 and gopkg.in/launchdarkly/go-sdk-common.v2 is replaced by github.com/launchdarkly/go-sdk-common/v3.
• The type lduser.User has been redefined to be an alias for ldcontext.Context. This means that existing application code referencing lduser.User can still work as long as it is treating the user as an opaque value, and not calling methods on it that were specific to that type.
• All methods that used the type lduser.User now use ldcontext.Context instead.
• lduser.NewUser and lduser.UserBuilder now create an instance of Context instead of User. This is as a convenience so that any code that was previously using these methods to construct a user, but did not reference the User type directly for the result, may still be usable without changes. It is still preferable to use the new constructors and builders for Context.
• The Secondary attribute which existed in User does not exist in Context and is no longer a supported feature.
• It was previously allowable to set a user key to an empty string. In the new context model, the key is not allowed to be empty. Trying to use an empty key will cause evaluations to fail and return the default value.
• If you were using JSON serialization to produce a representation of a User, the new type Context uses a different JSON schema, so any code that reads the JSON will need to be adjusted. If you are passing the JSON to other code that uses LaunchDarkly SDKs, make sure you have updated all SDKs to versions that use the new context model. (However, unmarshaling a Context from JSON data will still work correctly even if the JSON is in the old user format.)
• Types such as DataStore, which define the low-level interfaces of LaunchDarkly SDK components and allow implementation of custom components, have been moved out of the interfaces subpackage into a new subsystems subpackage. Some types have been removed by using generics: for instance, the interface type DataSourceFactory has been replaced by ComponentConfigurer[DataSource]. Application code normally does not refer to these types except possibly to hold a value for a configuration property such as Config.DataStore, so this change is likely to only affect configuration-related logic.

Changed (requirements/dependencies/build):

• The minimum Go version is now 1.18.

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 all types, fields, and methods that were deprecated as of the most recent 5.x release.
• Removed the Secondary meta-attribute in lduser.User and lduser.UserBuilder.
• The Alias method no longer exists because alias events are not needed in the new context model.
• The InlineUsersInEvents option no longer exists because it is not relevant in the new context model.

v5.10.0

[5.10.0] - 2022-07-05

Added:

• ldtestdata.FlagBuilder.VariationForAll and VariationForAllIndex: new names for the deprecated methods listed below.

Changed:

• It was possible to cause analytics event data to be lost by passing ldvalue.Raw(nil) or ldvalue.Raw(json.RawMessage("")) as a default value parameter to JSONVariation, or as the value of a custom user attribute, because a zero-length byte array is not a valid JSON value and would cause the event output to be malformed. The SDK now guards against this by encoding such a value as null in the event data. It is still possible to cause a similar problem by passing a malformed raw value as as ldvalue.Raw(json.RawMessage("{{{")); it is the caller's responsibility not to do so, as the purpose of json.RawMessage is to avoid unnecessary parsing and implies that the value is known to be syntactically valid.

Fixed:

• If a field in Config.ApplicationInfo is set to a string longer than 64 characters, the SDK will now log a warning and discard it, since the LaunchDarkly services cannot process such strings for these fields.
• Prevented a potential data race in LDClient.Initialized(). (#69)

Deprecated:

• ldtestdata.FlagBuilder.VariationForAllUsers and VariationForAllUsersIndex. These methods are being renamed because in the future, there will be other possible kinds of evaluation inputs that are not users, and these test methods will apply equally to those.

v5.9.0

[5.9.0] - 2022-03-22

Added:

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

5.8.1

[5.8.1] - 2022-01-19

Fixed:

• When using AllFlagsState to produce bootstrap data for the JavaScript SDK, the Go 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.

5.8.0

[5.8.0] - 2022-01-10

Added:

• Config.ServiceEndpoints provides a simpler way of setting custom service base URIs, if you are connecting to a LaunchDarkly Relay Proxy instance, a private LaunchDarkly instance, or a test fixture. Previously, this required setting a BaseURI property for each individual service (streaming, events, etc.). If using the Relay Proxy, simply remove any BaseURI calls in your SDK configuration and set the ServiceEndpoints property to ldcomponents.RelayProxyEndpoints(myRelayProxyUri) (use RelayProxyEndpointsWithoutEvents instead if your Relay Proxy instance does not have event forwarding enabled).

5.7.0

[5.7.0] - 2022-01-07

Added:

• HTTPConfigurationBuilder.Header allows adding custom HTTP headers to all of the SDK's requests.

Changed:

• The SDK will now log a message at Error level whenever it detects flag data that should not be possible according to LaunchDarkly's validation rules (for instance, a rule that references a nonexistent variation index, or a circular reference in flag prerequisites). Previously, such messages were only logged at Warn level and only if LoggingConfigurationBuilder.LogEvaluationErrors was enabled; that is still the default behavior for other kinds of errors (such as "flag not found"), but malformed data is considered a more serious error because it should not be possible and may require assistance from LaunchDarkly support.

Fixed:

• If the SDK detects a circular reference in flag prerequisites (for example, flag A has flag B as a prerequisite and vice versa), it will now refuse to evaluate the affected flags, returning the default value and an error reason of MALFORMED_FLAG. Previously, such a condition would cause infinite recursion and a stack overflow. LaunchDarkly does not allow circular references to be created in flag configurations, but under rare circumstances an SDK could incorrectly perceive such a state if it received updates out of order; or, the SDK could be configured to use data from a file that contained such references.