(chore) prepare for 3.0 #265
Conversation
|
Should be chore and not choir. Also, please update summary. Content is fine, but looks haphazard with the dangling |
CHANGELOG.md
Outdated
| @@ -1,5 +1,39 @@ | |||
| # Optimizely Java X SDK Changelog | |||
|
|
|||
| ## 3.0.0 | |||
| February 11, 2019 | |||
There was a problem hiding this comment.
Shouldn't this be February 13th?
| * 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. |
There was a problem hiding this comment.
We do not support this in the product yet. @nchilada I am probably late to the conversation, but I am assuming this is fine to put in?
There was a problem hiding this comment.
Yeah, I think this is okay. I believe this is already exposed in data export, and we're planning to support this in the results page in Q1.
And I used future tense just in case, despite being unhappy about the jarring tense 😂
This will ...
CHANGELOG.md
Outdated
| * 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`. | ||
| * Support for empty user IDs. | ||
| * Wrap the buffer reader in try...catch. |
There was a problem hiding this comment.
Should we have PRs linked here? @mikeng13 ?
There was a problem hiding this comment.
Yes, these should like to the respective PRs like we do in previous release notes.
There was a problem hiding this comment.
Hmm, we seemed to be inconsistent on that front... I did omit PR links in the centralized draft of the release notes, primarily for logistical reasons, but also because some changes couldn't be described by a single PR.
I'd say SDK releasers are free to add links, but they're not easy to determine for all changes, and I personally am not gonna require them.
There was a problem hiding this comment.
We've been inconsistent before but we should be consistent now. Going forward we should do it all our releases as I do consider this useful notes/info.
CHANGELOG.md
Outdated
| * 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`. | ||
| * Support for empty user IDs. | ||
| * Wrap the buffer reader in try...catch. |
There was a problem hiding this comment.
Hmm, we seemed to be inconsistent on that front... I did omit PR links in the centralized draft of the release notes, primarily for logistical reasons, but also because some changes couldn't be described by a single PR.
I'd say SDK releasers are free to add links, but they're not easy to determine for all changes, and I personally am not gonna require them.
CHANGELOG.md
Outdated
| * 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`. | ||
| * Support for empty user IDs. | ||
| * Wrap the buffer reader in try...catch. |
There was a problem hiding this comment.
After discussing offline, @thomaszurkan-optimizely is going to think of better wording than
Wrap the buffer reader in try...catch.
CHANGELOG.md
Outdated
|
|
||
| ### 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`. |
There was a problem hiding this comment.
Can you indent this line? It's supposed to be a sub-bullet point that clarifies the prior bullet point. Sorry for the confusing formatting!
CHANGELOG.md
Outdated
|
|
||
| ### 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. |
There was a problem hiding this comment.
| * 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. | |
| * 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. |
Sorry for the late change! But I think this could be more consistent with other in-code documentation
CHANGELOG.md
Outdated
| * 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 number in the inclusive range [-2⁵³, 2⁵³]. |
There was a problem hiding this comment.
| * 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 number in the inclusive range [-2⁵³, 2⁵³]. | |
| * 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, double, integer, or long in the inclusive range [-2⁵³, 2⁵³]. |
CHANGELOG.md
Outdated
| * 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 number in the inclusive range [-2⁵³, 2⁵³]. |
There was a problem hiding this comment.
| * `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 number in the inclusive range [-2⁵³, 2⁵³]. | |
| * `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, double, integer, or long in the inclusive range [-2⁵³, 2⁵³]. |
| * 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. |
There was a problem hiding this comment.
Yeah, I think this is okay. I believe this is already exposed in data export, and we're planning to support this in the results page in Q1.
And I used future tense just in case, despite being unhappy about the jarring tense 😂
This will ...
There was a problem hiding this comment.
Looks great! It sounds like @mikeng13 might still be interested in PR links (maybe along the lines of the @mjc1283 has added in optimizely/javascript-sdk#217?) but I've no complaints with the current content.
Summary