Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Bump LaunchDarkly.ServerSdk from 5.13.0 to 6.2.0 #79

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Bump LaunchDarkly.ServerSdk from 5.13.0 to 6.2.0 #79

wants to merge 1 commit into from

Conversation

dependabot-preview[bot]
Copy link

Bumps LaunchDarkly.ServerSdk from 5.13.0 to 6.2.0.

Release notes

Sourced from LaunchDarkly.ServerSdk's releases.

6.2.0

[6.2.0] - 2021-07-22

Added:

  • The SDK now supports evaluation of Big Segments. An Early Access Program for creating and syncing Big Segments from customer data platforms is available to enterprise customers.

6.1.0

[6.1.0] - 2021-06-22

Added:

  • The SDK now supports the ability to control the proportion of traffic allocation to an experiment. This works in conjunction with a new platform feature now available to early access customers.

6.0.0

[6.0.0] - 2021-06-09

This is a major rewrite that introduces a cleaner API design, adds new features, and makes the SDK code easier to maintain and extend. See the .NET 5.x to 6.0 migration guide for an in-depth look at the changes in 6.0.0; the following is a summary.

Added:

  • You can tell the SDK to notify you whenever a feature flag's configuration has changed (either in general, or in terms of its result for a specific user), using LdClient.FlagTracker.
  • You can monitor the status of the SDK's data source (which normally means the streaming connection to the LaunchDarkly service) with LdClient.DataSourceStatusProvider. This allows you to check the current connection status, and to be notified if this status changes.
  • You can monitor the status of a persistent data store with LdClient.DataStoreStatusProvider. This allows you to check whether database updates are succeeding, or to be notified if this status changes.
  • The TestData class in LaunchDarkly.Sdk.Server.Integrations 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.
  • HttpConfigurationBuilder.Proxy allows you to specify an HTTP/HTTPS proxy server programmatically, rather than using .NET's HTTPS_PROXY environment variable. That was already possibly to do by specifying an HttpClientHandler that had a proxy; this is a shortcut for the same thing.
  • HttpConfigurationBuilder.CustomHeader allows you to specify custom HTTP headers that should be added to every HTTP/HTTPS request made by the SDK.
  • HttpConfigurationBuilder.ResponseStartTimeout sets the timeout interval for "start of request until beginning of server response", which .NET represents as System.Net.HttpClient.Timeout. The SDK previously referred to this as ConnectTimeout, but it was not a real connection timeout in the sense that most TCP/IP frameworks use the term, so the new name more clearly defines the behavior.
  • There is now a DoubleVariation method for getting a numeric flag value as the double type (as opposed to FloatVariation which returns a float).
  • The Alias method of LdClient can be used to associate two user objects for analytics purposes with an alias event.
  • ConfigurationBuilder.Logging is a new configuration category for options related to logging. This includes a new mechanism for specifying where log output should be sent, instead of using the Common.Logging framework to configure this.
  • LoggingConfigurationBuilder.LogDataSourceOutageAsErrorAfter controls the new connection failure logging behavior described below under "behavioral changes".
  • The LaunchDarkly.Sdk.Json namespace provides methods for converting types like User and FeatureFlagsState to and from JSON.
  • The LaunchDarkly.Sdk.UserAttribute type provides a less error-prone way to refer to user attribute names in configuration, and can also be used to get an arbitrary attribute from a user.
  • The LaunchDarkly.Sdk.UnixMillisecondTime type provides convenience methods for converting to and from the Unix epoch millisecond time format that LaunchDarkly uses for all timestamp values.

Changed (requirements/dependencies/build):

  • The SDK's build targets are now .NET Standard 2.0, .NET Core 2.1, .NET Framework 4.5.2, .NET Framework 4.7.1, and .NET 5.0. This means it can be used in applications that run on .NET Core 2.1 and above, .NET Framework 4.5.2 and above, .NET 5.0 and above, or in a portable library that is targeted to .NET Standard 2.0 and above.
  • The SDK no longer has a dependency on Common.Logging. Instead, it uses a similar but simpler logging facade, the LaunchDarkly.Logging package, which has adapters for various logging destinations (including one for Common.Logging, if you want to keep an existing configuration that uses that framework).
  • The SDK no longer has a dependency on Newtonsoft.Json. It uses the System.Text.Json API internally on platforms where that is available; on others, such as .NET Framework 4.5.x, it uses a lightweight custom implementation. This removes the potential for dependency version conflicts in applications that use Newtonsoft.Json for their own purposes. Converting data types like User and LdValue to and from JSON with System.Text.Json will always work; converting them with Newtonsoft.Json requires an extra package, LaunchDarkly.CommonSdk.JsonNet.
  • The SDK's dependencies for its own implementation details are now LaunchDarkly.CommonSdk, LaunchDarkly.EventSource, LaunchDarkly.InternalSdk, and LaunchDarkly.JsonStream. You should not need to reference these assemblies directly, as they are loaded automatically when you install the main NuGet package LaunchDarkly.ServerSdk. Previously there was also a variant called LaunchDarkly.CommonSdk.StrongName that was used by the release build of the SDK, but that has been removed.

Changed (API changes):

  • The base namespace has changed: types that were previously in LaunchDarkly.Client are now in either LaunchDarkly.Sdk or LaunchDarkly.Sdk.Server. The LaunchDarkly.Sdk namespace contains types that are not specific to the server-side .NET SDK (that is, they will also be used by the Xamarin SDK): EvaluationDetail, LdValue, User, and UserBuilder. Types that are specific to the server-side .NET SDK, such as Configuration and LdClient, are in LaunchDarkly.Sdk.Server.
  • Many properties have been moved out of ConfigurationBuilder, into sub-builders that are specific to one area of functionality (such as streaming, or analytics events). See ConfigurationBuilder and Components.
  • User and Configuration objects are now immutable. To specify properties for these classes, you must now use User.Builder and Configuration.Builder.
  • The following things now use the type LdValue instead of JToken: custom attribute values in User.Custom; JSON flag variations returned by JsonVariation, JsonVariationDetail, and AllFlags; the optional data parameter of LdClient.Track.
  • EvaluationReason is now a single struct type rather than a base class.
  • LaunchDarkly.Client.Files.FileComponents has been moved to LaunchDarkly.Sdk.Server.Integrations.FileData.
  • LdClient.Initialized is now a read-only property rather than a method.
  • Interfaces for creating custom components, such as IFeatureStore, now have a new namespace (LaunchDarkly.Sdk.Server.Interfaces), new names, and somewhat different semantics due to changes in the SDK's internal architecture. Any existing custom component implementations will need to be revised to work with .NET SDK 5.x.
  • The ILdClient interface is now in LaunchDarkly.Sdk.Server.Interfaces instead of the main namespace.
  • The IConfigurationBuilder interface has been replaced by the concrete class ConfigurationBuilder.

Changed (behavioral changes):

  • In streaming mode, the SDK will now drop and restart the stream connection if either 1. it receives malformed data (indicating that some data may have been lost before reaching the application) or 2. you are using a database integration (a persistent data store) and a database error happens while trying to store the received data. In both cases, the intention is to make sure updates from LaunchDarkly are not lost; restarting the connection causes LaunchDarkly to re-send the entire flag data set. This makes the .NET SDK's behavior consistent with other LaunchDarkly server-side SDKs.

... (truncated)

Changelog

Sourced from LaunchDarkly.ServerSdk's changelog.

[6.2.0] - 2021-07-22

Added:

  • The SDK now supports evaluation of Big Segments. An Early Access Program for creating and syncing Big Segments from customer data platforms is available to enterprise customers.

[6.1.0] - 2021-06-22

Added:

  • The SDK now supports the ability to control the proportion of traffic allocation to an experiment. This works in conjunction with a new platform feature now available to early access customers.

[6.0.0] - 2021-06-09

This is a major rewrite that introduces a cleaner API design, adds new features, and makes the SDK code easier to maintain and extend. See the .NET 5.x to 6.0 migration guide for an in-depth look at the changes in 6.0.0; the following is a summary.

Added:

  • You can tell the SDK to notify you whenever a feature flag's configuration has changed (either in general, or in terms of its result for a specific user), using LdClient.FlagTracker.
  • You can monitor the status of the SDK's data source (which normally means the streaming connection to the LaunchDarkly service) with LdClient.DataSourceStatusProvider. This allows you to check the current connection status, and to be notified if this status changes.
  • You can monitor the status of a persistent data store with LdClient.DataStoreStatusProvider. This allows you to check whether database updates are succeeding, or to be notified if this status changes.
  • The TestData class in LaunchDarkly.Sdk.Server.Integrations 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.
  • HttpConfigurationBuilder.Proxy allows you to specify an HTTP/HTTPS proxy server programmatically, rather than using .NET's HTTPS_PROXY environment variable. That was already possibly to do by specifying an HttpClientHandler that had a proxy; this is a shortcut for the same thing.
  • HttpConfigurationBuilder.CustomHeader allows you to specify custom HTTP headers that should be added to every HTTP/HTTPS request made by the SDK.
  • HttpConfigurationBuilder.ResponseStartTimeout sets the timeout interval for "start of request until beginning of server response", which .NET represents as System.Net.HttpClient.Timeout. The SDK previously referred to this as ConnectTimeout, but it was not a real connection timeout in the sense that most TCP/IP frameworks use the term, so the new name more clearly defines the behavior.
  • There is now a DoubleVariation method for getting a numeric flag value as the double type (as opposed to FloatVariation which returns a float).
  • The Alias method of LdClient can be used to associate two user objects for analytics purposes with an alias event.
  • ConfigurationBuilder.Logging is a new configuration category for options related to logging. This includes a new mechanism for specifying where log output should be sent, instead of using the Common.Logging framework to configure this.
  • LoggingConfigurationBuilder.LogDataSourceOutageAsErrorAfter controls the new connection failure logging behavior described below under "behavioral changes".
  • The LaunchDarkly.Sdk.Json namespace provides methods for converting types like User and FeatureFlagsState to and from JSON.
  • The LaunchDarkly.Sdk.UserAttribute type provides a less error-prone way to refer to user attribute names in configuration, and can also be used to get an arbitrary attribute from a user.
  • The LaunchDarkly.Sdk.UnixMillisecondTime type provides convenience methods for converting to and from the Unix epoch millisecond time format that LaunchDarkly uses for all timestamp values.

Changed (requirements/dependencies/build):

  • The SDK's build targets are now .NET Standard 2.0, .NET Core 2.1, .NET Framework 4.5.2, .NET Framework 4.7.1, and .NET 5.0. This means it can be used in applications that run on .NET Core 2.1 and above, .NET Framework 4.5.2 and above, .NET 5.0 and above, or in a portable library that is targeted to .NET Standard 2.0 and above.
  • The SDK no longer has a dependency on Common.Logging. Instead, it uses a similar but simpler logging facade, the LaunchDarkly.Logging package, which has adapters for various logging destinations (including one for Common.Logging, if you want to keep an existing configuration that uses that framework).
  • The SDK no longer has a dependency on Newtonsoft.Json. It uses the System.Text.Json API internally on platforms where that is available; on others, such as .NET Framework 4.5.x, it uses a lightweight custom implementation. This removes the potential for dependency version conflicts in applications that use Newtonsoft.Json for their own purposes. Converting data types like User and LdValue to and from JSON with System.Text.Json will always work; converting them with Newtonsoft.Json requires an extra package, LaunchDarkly.CommonSdk.JsonNet.
  • The SDK's dependencies for its own implementation details are now LaunchDarkly.CommonSdk, LaunchDarkly.EventSource, LaunchDarkly.InternalSdk, and LaunchDarkly.JsonStream. You should not need to reference these assemblies directly, as they are loaded automatically when you install the main NuGet package LaunchDarkly.ServerSdk. Previously there was also a variant called LaunchDarkly.CommonSdk.StrongName that was used by the release build of the SDK, but that has been removed.

Changed (API changes):

  • The base namespace has changed: types that were previously in LaunchDarkly.Client are now in either LaunchDarkly.Sdk or LaunchDarkly.Sdk.Server. The LaunchDarkly.Sdk namespace contains types that are not specific to the server-side .NET SDK (that is, they will also be used by the Xamarin SDK): EvaluationDetail, LdValue, User, and UserBuilder. Types that are specific to the server-side .NET SDK, such as Configuration and LdClient, are in LaunchDarkly.Sdk.Server.
  • Many properties have been moved out of ConfigurationBuilder, into sub-builders that are specific to one area of functionality (such as streaming, or analytics events). See ConfigurationBuilder and Components.
  • User and Configuration objects are now immutable. To specify properties for these classes, you must now use User.Builder and Configuration.Builder.
  • The following things now use the type LdValue instead of JToken: custom attribute values in User.Custom; JSON flag variations returned by JsonVariation, JsonVariationDetail, and AllFlags; the optional data parameter of LdClient.Track.
  • EvaluationReason is now a single struct type rather than a base class.
  • LaunchDarkly.Client.Files.FileComponents has been moved to LaunchDarkly.Sdk.Server.Integrations.FileData.
  • LdClient.Initialized is now a read-only property rather than a method.
  • Interfaces for creating custom components, such as IFeatureStore, now have a new namespace (LaunchDarkly.Sdk.Server.Interfaces), new names, and somewhat different semantics due to changes in the SDK's internal architecture. Any existing custom component implementations will need to be revised to work with .NET SDK 5.x.
  • The ILdClient interface is now in LaunchDarkly.Sdk.Server.Interfaces instead of the main namespace.
  • The IConfigurationBuilder interface has been replaced by the concrete class ConfigurationBuilder.

Changed (behavioral changes):

  • In streaming mode, the SDK will now drop and restart the stream connection if either 1. it receives malformed data (indicating that some data may have been lost before reaching the application) or 2. you are using a database integration (a persistent data store) and a database error happens while trying to store the received data. In both cases, the intention is to make sure updates from LaunchDarkly are not lost; restarting the connection causes LaunchDarkly to re-send the entire flag data set. This makes the .NET SDK's behavior consistent with other LaunchDarkly server-side SDKs.
  • However, if you have set the caching behavior to "cache forever" (see PersistentDataStoreConfiguration), the stream will not restart after a database error; instead, all updates will still be accumulated in the cache, and will be written to the database automatically if the database becomes available again.
  • Logging now uses a simpler, more stable set of logger names instead of using the names of specific implementation classes that are subject to change. General messages are logged under LaunchDarkly.Sdk.Server.LdClient, while messages about specific areas of functionality are logged under that name plus .DataSource (streaming, polling, file data, etc.), .DataStore (database integrations), .Evaluation (unexpected errors during flag evaluations), or .Events (analytics event processing).
  • Network failures and server errors for streaming or polling requests were previously logged at Error level in most cases but sometimes at Warn level. They are now all at Warn level, but with a new behavior: if connection failures continue without a successful retry for a certain amount of time, the SDK will log a special Error-level message to warn you that this is not just a brief outage. The amount of time is one minute by default, but can be changed with the new LogDataSourceOutageAsErrorAfter option in LoggingConfigurationBuilder.

... (truncated)

Commits

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
  • @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

  • Update frequency (including time of day and day of week)
  • Pull request limits (per update run and/or open at any time)
  • Out-of-range updates (receive only lockfile updates, if desired)
  • Security updates (receive only security updates, if desired)

@dependabot-preview dependabot-preview bot added the dependencies Pull requests that update a dependency file label Jul 23, 2021
@dependabot-preview dependabot-preview bot mentioned this pull request Jul 23, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
0 participants