Development:Planning:Software Update
Jump to navigation
Jump to search
Requirements
- can build in a 10.3/10.3.9 SDK/gcc3.3 and 10.4/10.4u/gcc4 Universal configuration
- Compatible license
- Approval to land in cvs (if not using mozUpdate) - mento prefers landing source code instead of binary drops
- https capabilities
- Everything needs to be either https or signed (signing is an option for the Sparkle downloads, but there's a logistical issue that would come with that)
- Update checking (OS version, etc.)
- say, 1.6.x updates to 2.0.x at some point unless you're running 10.3, in which case you only get 1.6.x updates
- and if you move to 10.4, do you get re-offered 2.0.x
- provide a way to turn off update checking from inside the app (unlike adium - with apologies to cbarrett for the jab)
- one thing i don't like about sparkle is that it doesn't check to see if you have permission to update the app first
- We should only enable update checking in official release builds
- en-only and ML Camino
- what if your language drops from ML in a major update?
- Localization of required strings
- This is significant UI, and it needs to be localized (i.e., Gecko chrome strings bug is a no-go here)
- Automated generation of update and update notification
- Bouncer/download counts
Potential requirements
- Resuming lost connections
- Background/throttled downloads
- Remind me later
- Don't remind me again???
- Install update later
Concerns
- QA
- Documentation
- Gecko
- Well-maintained
- User Experience
- ardissone has some concerns with the over-promptiness of the proposed Sparkle2 story
Comparison Table
<tdstyle="background: #8F8;">Yes <tdstyle="background: #8F8;">YesRequirement | mozUpdate | Sparkle | Option 3 |
---|---|---|---|
Can build as 10.3/10.4 Universal | |||
License | Tri-License | MIT [1] | |
cvs Approval | In tree | ||
Can land source code (instead of binary drops) |
In tree | ||
Uses https for binary downloads | |||
Uses https for "need to update" notice downloads | |||
https server available | |||
Supports fine-grained checking for version/OS pairs | Not directly, but we should be able to point to different URLs by OS version | ||
Can disable update checking within Camino | Yes | Yes | |
Verifies user has permission to update first | Supports users authenticating | ||
Can enable updates/update checking only in official release builds | Yes | ||
Can handle ML as well as en-only Camino | Yes, but we have to localize it | Yes | |
UI string localization | Yes, but we have to localize it | Yes | |
Release automation | |||
Bouncer/download counts | |||
Desirables | |||
Support for resuming lost connections | |||
Can download in background | |||
Can download at low speed to not affect connection | |||
Can remind to download later | Yes | ||
Can install later once downloaded | |||
Good UI/UE (not lots of prompting, esp. at launch) |
We control prompting | At startup, but we could modify that | |
Other concerns | |||
Expanded QA requirements | If we do partial updates, yes | Minimal; it's just an over-install | |
Documentation | Poor/missing for many parts | Good | |
Complexity added to the app e.g. wrapping Gecko |
It can be fairly separate, but it's code we need to write | Minimal | |
Actively maintained and supported | Yes, Firefox at least uses it (and TB?) | Yes, 188+ Apps using it | |
Color key | |||
Present | Unknown | Missing |