If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Include Firefox version in desktop client records

RESOLVED FIXED in Firefox 27

Status

Cloud Services
Firefox Sync: Backend
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: rnewman, Assigned: rnewman)

Tracking

(Blocks: 1 bug, {dev-doc-needed})

unspecified
mozilla29
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox27 fixed, firefox28 fixed, firefox29 fixed)

Details

(Whiteboard: [qa+][see bug 956936 for verification])

Attachments

(1 attachment)

Comment hidden (empty)
(Assignee)

Updated

4 years ago
Blocks: 956445
(Assignee)

Comment 1

4 years ago
Created attachment 8355708 [details] [diff] [review]
Include version in desktop Sync client records.
Attachment #8355708 - Flags: review?(gps)
Whiteboard: [qa?]
Comment on attachment 8355708 [details] [diff] [review]
Include version in desktop Sync client records.

Review of attachment 8355708 [details] [diff] [review]:
-----------------------------------------------------------------

I'm going to take the [somewhat harsh] step of cancelling review until I get more details on what the plan is. Sure, I could rubber stamp this. But I'd like to know what your plans are for migration.

IIRC, we had talked about using a set of feature strings instead of a single version number. We had also talked about other metadata to attach to client records to allow devices to be better identified (for use in e.g. device management wizards). While I don't want to scope creep, I want to know if this is going to be the final change to the client record for 1.1 or whether it will be the first of many. If it's the only change, I'm curious why we're exposing the application version number instead of "supported sync protocol versions" or something akin to that.
Attachment #8355708 - Flags: review?(gps)
Flags: needinfo?(rnewman)
(Assignee)

Comment 3

4 years ago
(In reply to Gregory Szorc [:gps] from comment #2)

> But I'd like to know what your plans are for migration.

Drawing on

https://wiki.mozilla.org/User_Services/Sync/v1#Migration_strategy

and the UX flows (which, alas, aren't public): here's the feature list I intend to support.

* If a user has only one device, we can recommend that they migrate to FxA.
* If a user has multiple devices, and they're all running 29 or higher, we can recommend that they migrate.
* Otherwise, we don't.
* And to reduce partitioning, we want to write a migration sentinel (meta/credentials?) which contains the bundle of stuff they need to set up their Firefox Account on other machines. That will allow for automated migration once you sign in on one of your devices.

This is deliberately very coarse. Ideally we'd have a full capabilities model, but in the interests of time (and because we intend to simultaneously release on each platform) I'm using the software version as a proxy.

We're also interested in the version because it allows for product/marketing level decisions, not engineering: e.g., maybe we only want users to migrate once they have a v30 Firefox, or somesuch.

I don't intend to make any other changes to the client record. The only other change I could imagine is to write an "I'm dead" client record, but we could do the same thing with deleted: true.

I remain quietly hopeful that future plans will include proper device management, service discovery, etc., and that those plans won't be based on Sync's dodgy design.
Flags: needinfo?(rnewman)
Proxy values and distributed clients do not mix. I know you know this.

I would strongly prefer you add two values: sync_protocol_version (or similar) and application_version to convey the distinct meanings. But, you can strong arm me into r+'ing the current patch w/ proxy value. I have no doubt to trust your judgement here.

Please request review from me at your leisure.
(Assignee)

Updated

4 years ago
Blocks: 956936
(Assignee)

Comment 5

4 years ago
(In reply to Gregory Szorc [:gps] from comment #4)

> I would strongly prefer you add two values: sync_protocol_version (or
> similar) and application_version to convey the distinct meanings.

Yup, agreed.

Filed two follow-ups to include supported Sync versions in the client payloads. Both should be rubber-stamps, because they'll be another thread through the same hole.

Also marking this as dev-doc-needed so I can update the protocol docs accordingly.
Keywords: dev-doc-needed
Whiteboard: [qa?] → [qa+]
(Assignee)

Comment 6

4 years ago
Comment on attachment 8355708 [details] [diff] [review]
Include version in desktop Sync client records.

This patch will be just Firefox version.
Attachment #8355708 - Flags: review?(gps)
(Assignee)

Comment 7

4 years ago
Clarifying bug title (to match the Android bug).
Summary: Include version in desktop client records → Include Firefox version in desktop client records
Attachment #8355708 - Flags: review?(gps) → review+
(Assignee)

Comment 8

4 years ago
https://hg.mozilla.org/services/services-central/rev/6d5b0207c771

Will land this, and Bug 956445 and Bug 956936, in s-c.
Whiteboard: [qa+] → [qa+][fixed in services]
https://hg.mozilla.org/mozilla-central/rev/6d5b0207c771
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Whiteboard: [qa+][fixed in services] → [qa+]
Target Milestone: --- → mozilla29
(Assignee)

Updated

4 years ago
Blocks: 695134
(Assignee)

Comment 10

4 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/7c5ec27e3894
Whiteboard: [qa+] → [qa+][see bug 956936 for verification]
(Assignee)

Updated

4 years ago
status-firefox28: --- → fixed
status-firefox29: --- → fixed
(Assignee)

Comment 11

4 years ago
https://hg.mozilla.org/releases/mozilla-beta/rev/e00e81e924c7
(Assignee)

Updated

4 years ago
status-firefox27: --- → fixed
You need to log in before you can comment on or make changes to this bug.