- From: Evan Stade <notifications@github.com>
- Date: Wed, 25 Aug 2021 10:20:21 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/446/905725612@github.com>
> The best we can do is "is it different"? I *think* we'd be OK with this and still using it to help manage updates. A lower version number might indicate that a user ought to be down-graded and I can't think of a reason not to support that. We are concerned about maintaining functionality (at least for now) for apps that don't specify a version at all. Thus, Chrome's ideal behavior would be something like: - store the `version` specified during most recent update/install - when processing a manifest for update - if `version` is not found, use current update procedure (i.e. compare all manifest fields and image contents to determine need for updating, but throttle this to ~once/day) - if `version` is found - and matches saved `version`, _do not_ update - and does not match saved `version`, _do_ update, without throttling (probably -- might need to consider *some* amount of throttling still) - (possibly) display `version` in user-visible app info surface(s), to assist with debugging in the field If I'm not mistaken, the only part of the above behavior which turns into actual spec is > if `version` is found, and matches saved `version`, _do not_ update App developers should be motivated to use `version` because it helps reduce unnecessary bandwidth usage (i.e. the user agent does not need to download all images again to make sure they haven't changed) and makes updating more predictable (reduces need for user agent to throttle). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/manifest/issues/446#issuecomment-905725612
Received on Wednesday, 25 August 2021 17:20:34 UTC