[Version History] Update behavior - Manifest and SW/app update sync

[nhoizey]

I understand that the changelog is shown only after the update of the manifest is done.

However, the changelog is about the app update, including or not a new Service Worker.

How do you plan to sync updates of the manifest and the site/app (and Service Worker)?

[docluv]

So far the only concern my clients have had with the manifest update is the icons. And even then I rarely change the icon names, just the actual files. This is typically done when a design/style logo changes. Like Nick expressed it is more about application assets updating via the service worker. If I need to notify the user I typically post a message to the UI and alert them from there to any actions they need to take or to give them a feature update notification. I have started adding a version # on a page like about or configuration just so I an my stakeholders know if the latest has been 'updated' on the target device. As I read this explaining the platform will be ignorant of most updates, unless the bits in the manifest file update. So this is not a clean option AFAIK. Using an RSS like feed is nice, but really requires the platform to poll. Instead if should have some sort of API from the Service Worker to update.

[stanleyhon]

How do you plan to sync updates of the manifest and the site/app (and Service Worker)?

@nhoizey, I actually considered the same question while thinking about the explainer. My initial plan was to have changelog information be a special higher importance member of the manifest.json. In this version we would poll when reasonable to see if there are any updates to changelog related information and immediately update that information. This would solve the problem you put forward.

However, when I looked into this solution deeper I found a few things that made me reconsider. Firstly, the way PWAs update in Chrome and Edge currently is actually "pretend" in that we simply reinstall the PWA if updates are required. There are some architectural reasons why this is the case but I think this alone is not a good justification alone for not having real-time changelog updates.

So looking further, I discovered that in the W3C specification for Web App Manifests there is an open issue on updating. In addition to this, I would envision that changelog be added to this specification eventually.

This leads me to my eventual conclusion that updating is a problem that the Web App Manifest as a whole needs to address. Thus I don't believe that the changelog feature we are discussing here should attempt to solve a wider problem of the Web App Manifest updating as a whole.

This is the main reasoning I decided to put forward changelog updating with no additions/modifications to how PWAs update today. Then once Web App Manifests figure out how the updating story looks - user agents can follow suit and implement this and changelogs get this 'for free'.

@docluv, please feel free to correct me if I have distilled your comments different to what you intended but mainly I am reading your comment as:

• You agree that it's important to consider synchronization of the web content and the changelog info (i.e. they should be in sync in some how), this of which I hope my above comment addresses it somewhat
• The user agent/platform is ignorant if the web content updates. I think this is closely related to what I discussed above too - but I would add that the entire manifest.json is also being ignored in the current iteration of PWAs until some type of manifest.json updating mechanism is in place.
• Lastly, You suggest if we could have a some API exposed where PWAs can simply call to indicate an update occurred. I like this idea, but I think this suggestion is for Web App Manifest updating as a whole and not specific to changelogs as a feature.

From writing these responses, I think the main theme is that we'd all like PWAs to update in a better fashion but my thinking is that adding changelogs to the manifest.json should not be gated on us figuring out a better PWA update story.

[nhoizey]

@stanleyhon @docluv reading both your comments, I agree we need a way to sync updates of the manifest and the app.

Can we suppose updating the app comes with updating the Service Worker?

Could we then find a way to manage a version id (a number, semver or not, a name, anything…) in the Service Worker, and use it to show in the changelog which is the version currently running, and if there is a new one waiting for the update process to run?

[stanleyhon]

manage a version id ... use it to show in the changelog which is the version currently running

In the current design put forward in the explainer - this is possible. A PWA developer can include changelog->version and a URL to a changelog such as "changelogv5.json".

When the user views the changelog, it will show changelogv5.json, even if the real-time state on the web has the URL to the changelog updated to changelogv6.json. This is because until the 'update' occurs (and I use quotes because Edge actually just reinstalls right now) - the internal state will still point to the older changelog.

I believe one source of complexity here is that we are trying to reconcile many different things that can change and try to represent it in a single way. For example:

• The manifest.json may be modified
• The web content the PWA is serving is modified
• The service worker may itself change without the manifest.json changing.

This explainer puts forward a way for the developer to highlight any of the above, as desired. As I have mentioned in other places - this should be a deliberate "moment" that a PWA developer desires, not necessarily every bug-fix or small update. This explainer is designed with a version ID (changelog->version) not tied to any actual PWA functionality. Allowing the Web App Manifest spec full freedom to use manifest_root->version for purposes exact as you have described.

To bring us back to the opening question here - "How do Manifest updates and SW/app updates sync". I think the answer is they will not be able to sync perfectly until PWA updating is formally defined as per https://github.com/w3c/manifest/issues/446.

The explainer is focused on how we show information about new features in the PWA from the PWA developer rather than the vehicle, or mechanism in which these updates occur.

Could we then find a way to manage a version id (a number, semver or not, a name, anything…) in the Service Worker, and use it to show in the changelog which is the version currently running, and if there is a new one waiting for the update process to run?

This sounds quite reasonable but is in my opinion a suggestion for how we manage PWA updates. The main link back to changelogs is that when viewing changelogs we leverage this mechanism to display what version is currently running and whether the user should update.