Locking down Google Gears to a particular version

[jcowley]

We are currently looking at using Google Gears for a project that
requires offline capability, but a question has arisen over the
stability of the Gears browser plugin and API. Given that Gears is
currently only at version 0.2, we are concerned that if a user
upgrades to a newer version that it might break our application.

Does anyone know if it would be possible to prevent users from
upgrading to newer versions and how it can be done? Is it at all
feasible to create our own version of the Gears plugin that will not
conflict with the official one (with very little time and resources)?

I would be grateful for any opinions.

Thanks.

[Aaron Boodman]

On Fri, Mar 28, 2008 at 3:42 AM, jcowley <jaco...@gmail.com> wrote:
> We are currently looking at using Google Gears for a project that
> requires offline capability, but a question has arisen over the
> stability of the Gears browser plugin and API. Given that Gears is
> currently only at version 0.2, we are concerned that if a user
> upgrades to a newer version that it might break our application.

We're almost to version 0.3, if that helps your case at all :). But to
be clear, we take our role as API providers very seriously, because we
know that applications like Remember the Milk and Buxter, as well as
our own products like Google Reader are depending on us. We would
never knowingly break existing applications unless we had no other
option (for example, because of a security issue). We spend a crazy
amount of time obsessing over how to design APIs that are both forward
compatible with what we might want to do in the future and backward
compatible with things we have already done and people are using.

To summarize: the 0.x version and "beta" before our name should be
taken as an indication that we might break existing APIs. Rather, they
mean we know the current API set is incomplete, and we are adding new
APIs and extensions to existing ones very quickly:
http://code.google.com/p/google-gears/w/list

> Does anyone know if it would be possible to prevent users from
> upgrading to newer versions and how it can be done? Is it at all
> feasible to create our own version of the Gears plugin that will not
> conflict with the official one (with very little time and resources)?

It is certainly possible to create a version of the Gears installer
that does not autoupdate. It's also possible to change enough of the
identifiers so that your version of Gears (let's call it "Years") can
coexist side by side with the official Gears. I would strongly caution
against doing this, however, for three reasons:

1) We would not be able to update users in case of security problems.
2) Your application won't be able to take advantage of future
improvements to Gears
3) It will be a lot of work to run your own update system and
continually merge changes from official Gears into Years to deal with
1) and 2)

But in the end, you should do what's right for your application. If
you want to have complete control over the version of Gears you rely
on, you can do that. But you shouldn't do it because you think we
might break the APIs at any moment, because we hope to never have to
do that.

HTH,

- a

[Aaron Boodman]

On Fri, Mar 28, 2008 at 8:22 AM, Aaron Boodman <a...@google.com> wrote:
> know that applications like Remember the Milk and Buxter, as well as

*Buxfer

> To summarize: the 0.x version and "beta" before our name should be
> taken as an indication that we might break existing APIs. Rather, they

*should not be taken

:: sigh ::

Must remember not to send mail before coffee.

- a

[jcowley]

Thanks for your reply Aaron, that is very helpful. Given what you have
said I think we would be very unlikely to go down the route of
maintaining our own version of Gears.

Jason