Chrome Release Cycle
docs.google.com
docs.google.com
I'm sure I'd be singing a different tune if it broke my browser during a silent update.
This is probably the best solution, as it gives you the most control over updates, and applies to all software system-wide. You're not forced to install updates at any time, and you can disable the notifications if you want.
Chrome just starts for me. I'm happy with it.
"Some slides have failed to load and may appear blank. Click OK to try reloading the presentation, or cancel to continue viewing."
So Chrome hasn't completely ridded itself of modal popups just yet, though it's happens infrequently enough that I was pretty surprised.
If only we could essentially rely on all our users' browsers being up-to-date!
One possible negative effect is that updates get installed later (an average session length later), I wonder whether that’s offset by people not installing updates when the browser starts because they have something better to do?
Calibre tells me about a new release every single time I open it, they seem to release almost daily.
Sadly the "update" button on that dialog merely opens the web-browser, where you have to manually download and install the new version. Oh, and that is a 60MB(!) download every time.
The procedure is so absurd that it's actually amusing again. That's why I'm still doing it, I guess, even though after 20 or 30 updates I still haven't noticed any visible change to the software.
I rely heavily on the information saved by Chrome every time I use a form and I noticed how it doesn't save it when I use the beta version. Now that's fine because I can just use the last non-beta release just like everybody else but on the current one (at least on Windows 7) I can't access those saved values if the form is loaded by ajax into some iframe. It's really annoying.
I just wish google was a bit more subtle about wishing people search on google again when looking for previously viewed sites.
On the other hand, the silent updates are a blessing, and good features are another way of attracting users.
http://src.chromium.org/svn/trunk/src/chrome/common/chrome_s...
They do this even for fundamental features of the browser. For example, there's four different process models available:
http://dev.chromium.org/developers/design-documents/process-...
For planning software releases, I take inspiration from Chrome, Ubuntu, and Microsoft. They all have different release cycles, it's interesting to compare them.
Chrome: agile, 12 weekly releases, subtle upgrades, parallel versions with different stability levels.
Ubuntu: fixed six monthly schedule, well advertised schedule (e.g. http://www.youtube.com/watch?v=107E4RXNxYc) means difficult for them not to release on time, it's a selling point. Every 24 months long term support release.
Microsoft: major products released approximately every three years. Heavy marketing efforts around releases rather than features. Service pack releases and patches released on an ongoing basis.
I guess Chrome has less of an enterprise install base, which means they are more able to release on an ongoing basis. Enterprise IT teams like to install known good releases and not let other the vendors manage the upgrades.
If IE had been engineered in the same way, we never would have gotten into the IE 6 trap and when all browser manufacturers adopt this strategy, web technology will move much more quickly.