Preparing for 3.0.0 release

CHANGELOG.rst

@@ -1,3 +1,103 @@
+3.0.0
+-----
+
+March 1st, 2019
+
+The 3.0 release improves event tracking and supports additional audience targeting functionality.
+
+New Features:
+~~~~~~~~~~~~~
+
+-  Event tracking:
+
+   -  The ``track`` method now dispatches its conversion event
+      *unconditionally*, without first determining whether the user is
+      targeted by a known experiment that uses the event. This may
+      increase outbound network traffic.
+   -  In Optimizely results, conversion events sent by 3.0 SDKs are
+      automatically attributed to variations that the user has
+      previously seen, as long as our backend has actually received the
+      impression events for those variations.
+   -  Altogether, this allows you to track conversion events and
+      attribute them to variations even when you don’t know all of a
+      user’s attribute values, and even if the user’s attribute values
+      or the experiment’s configuration have changed such that the user
+      is no longer affected by the experiment. As a result, **you may
+      observe an increase in the conversion rate for
+      previously-instrumented events.** If that is undesirable, you can
+      reset the results of previously-running experiments after
+      upgrading to the 3.0 SDK.
+   -  This will also allow you to attribute events to variations from
+      other Optimizely projects in your account, even though those
+      experiments don’t appear in the same datafile.
+   -  Note that for results segmentation in Optimizely results, the user
+      attribute values from one event are automatically applied to all
+      other events in the same session, as long as the events in
+      question were actually received by our backend. This behavior was
+      already in place and is not affected by the 3.0 release.
+
+-  Support for all types of attribute values, not just strings.
+
+   -  All values are passed through to notification listeners.
+   -  Strings, booleans, and valid numbers are passed to the event
+      dispatcher and can be used for Optimizely results segmentation. A
+      valid number is a finite float or numbers.Integral in the inclusive range [-2⁵³,
+      2⁵³].
+   -  Strings, booleans, and valid numbers are relevant for audience
+      conditions.
+
+-  Support for additional matchers in audience conditions:
+
+   -  An ``exists`` matcher that passes if the user has a non-null value
+      for the targeted user attribute and fails otherwise.
+   -  A ``substring`` matcher that resolves if the user has a string
+      value for the targeted attribute.
+   -  ``gt`` (greater than) and ``lt`` (less than) matchers that resolve
+      if the user has a valid number value for the targeted attribute. A
+      valid number is a finite float or numbers.Integral in the inclusive range [-2⁵³,
+      2⁵³].
+   -  The original (``exact``) matcher can now be used to target
+      booleans and valid numbers, not just strings.
+
+-  Support for A/B tests, feature tests, and feature rollouts whose
+   audiences are combined using ``"and"`` and ``"not"`` operators, not
+   just the ``"or"`` operator.
+-  Datafile-version compatibility check: The SDK will remain
+   uninitialized (i.e., will gracefully fail to activate experiments and
+   features) if given a datafile version greater than 4.
+-  Updated Pull Request template and commit message guidelines.
+
+Breaking Changes:
+~~~~~~~~~~~~~~~~~
+
+-  Previously, notification listeners were only given string-valued user
+   attributes because only strings could be passed into various method
+   calls. That is no longer the case. You may pass non-string attribute
+   values, and if you do, you must update your notification listeners to
+   be able to receive whatever values you pass in.
+
+Bug Fixes:
+~~~~~~~~~~
+
+-  Experiments and features can no longer activate when a negatively
+   targeted attribute has a missing, null, or malformed value.
+
+   -  Audience conditions (except for the new ``exists`` matcher) no
+      longer resolve to ``false`` when they fail to find an legitimate
+      value for the targeted user attribute. The result remains ``null``
+      (unknown). Therefore, an audience that negates such a condition
+      (using the ``"not"`` operator) can no longer resolve to ``true``
+      unless there is an unrelated branch in the condition tree that
+      itself resolves to ``true``.
+
+-  Updated the default event dispatcher to log an error if the request
+   resolves to HTTP 4xx or 5xx. (`#140`_)
+-  All methods now validate that user IDs are strings and that
+   experiment keys, feature keys, feature variable keys, and event keys
+   are non-empty strings.
+
+.. _#140: https://github.com/optimizely/python-sdk/pull/140
+
 2.1.1
 -----
 

optimizely/version.py

@@ -1,4 +1,4 @@
-# Copyright 2016-2018, Optimizely
+# Copyright 2016-2019, Optimizely
 # Licensed under the Apache License, Version 2.0 (the "License");
 # you may not use this file except in compliance with the License.
 # You may obtain a copy of the License at
@@ -11,5 +11,5 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-version_info = (2, 1, 1)
+version_info = (3, 0, 0)
 __version__ = '.'.join(str(v) for v in version_info)