Add a manifest option for the declaration the "version" of the web application

[songql]

Whether it is a Web Application or a PWA (Progressive Web Application), it is a type of Application. Generally, the difference from other operating systems and desktop applications is whether the installation or deployed on the server or the client. With the emergence of technologies such as HTML5 and WASM, and the development of frameworks such as NodeJS and Electron/NW.js, Web technologies are rapidly occupying the territory of client-side development. Additionally, both Google Play and Microsoft Store already support offline PWA installers.

Based on the above, as a type of Application, Web Application should also define version attributes in the develop standard just like applications of other operating systems.

We can refer to the version methods defined by other operating system applications to formulate the version identification of the Web Application:

Platform	Host File	Keys
MS Windows .exe	resource.rc	ProductVersion
Mac .app	info.plist	CFBundleShortVersionString, CFBundleVersion
iOS .ipa	info.plist	CFBundleShortVersionString, CFBundleVersion
Android .apk	AndroidManifest.xml	versionCode, versionName
Chrome Extension .crx	manifest.json	version
NodeJS	package.json	version

And lots of people are asking questions about the PWA version online, and all kinds of weird solutions like:

• PWA - how do I specify a version?
• My PWA web app keep showing old version after a new release on Safari (but works fine on chrome)?
• custom PWA version management
• How to display a "new version available" for a Progressive Web App
• PWA force refresh when new version released?

Therefore, it is proposed to add a version attribute member object in manifest. The member object contains two attributes, namely code and name, where: code is an integer, which is incremented according to the update of the Web Application; name is text, which can be set by the developer to any user-friendly string, such as 1.0.0.

Specific examples are as follows:

{
  "version": {
    "code": 1,
    "name": "v1.0.0"
  }
}

The defined version attribute can provide the Web Application with access capabilities through Web API also, which can be used in more scenarios that developers needed, such as version display in web applications, offline PWA upgrade detection, etc.

Only by providing developers with more capabilities, Web Applications will flourish in the application ecosystem. Let’s move forward step by step!

[tomayac]

FWIW, the MiniApp Manifest spec, which extends the present spec, has a "version" field.

[aarongustafson]

We also included this in our proposal for a change log/version history: w3c/manifest-app-info#1

[alancutter]

@songql do you have affiliation with the MiniApp Manifest spec? Is this an effort to upstream the existing version field? If so it would be great to hear examples of it being used in that context.

[songql]

FWIW, the MiniApp Manifest spec, which extends the present spec, has a "version" field.

Thank you for your response.
I have try develop MiniApps at 2017, and had some understanding of features and concepts of it.
W3C is organizing the develop standards for MiniApps right now.
This proposal does refer to the concepts of MiniApps and Android.

[songql]

We also included this in our proposal for a change log/version history: w3c/manifest-app-info#1

Thank you for sharing your insights.
The trend of web application ecology will promotes the implementation of this feature.

[songql]

@songql do you have affiliation with the MiniApp Manifest spec? Is this an effort to upstream the existing version field? If so it would be great to hear examples of it being used in that context.

I'm a member of the MiniApps working group, but haven't proposal for it yet.
I think that MiniApps is a special web application, and web application is more extensive, so it can be regarded as the upstream specification.
I believe that the web ecosystem is developing rapidly, and web applications will or should instead some kind native applications in the future. The usage of version numbers by other applications can also be referred to by web applications.

[espinr]

The existing versioning proposal in the MiniApp manifest responds mainly to the demand for distributing the apps in marketplaces or directories and for the user agents to manage the different versions of the same application (identified by app_id) in terms of caching and operation.

The format is exactly as you, @songql, suggested:

{
    "version: {
        "code": [integer],
        "name": [human-readable-version]
    }
}

The version.code member holds the version number used to determine whether one version is more recent than another. On the other hand, version.name aims to be shown to the users, and it should follow the Semantic Versioning patterns.

This proposal is based on some similar approaches to indicate the

Android manifest:

<manifest 
          android:versionCode=1
          android:versionName="1.0.0">
</manifest>

Quick App's manifest:

{
  "versionName": "1.0",
  "versionCode": 1,
}

HarmonyOS config.json file:

{
  "app": {
    "version": {
        "code": 1,
        "name": "1.0"
    }
}

So, this version member is aligned to the w3c/manifest-app-info#1 . We mentioned this today in our monthly meeting. The MiniApp WG is happy to discuss a potential convergence if this could be interesting for the Web App manifest (or App Info extension).

[songql]

So, this version member is aligned to the w3c/manifest-app-info#1 . We mentioned this today in our monthly meeting. The MiniApp WG is happy to discuss a potential convergence if this could be interesting for the Web App manifest (or App Info extension).

@espinr Thanks for your response. I'm glad doing something for web standardization.
Both MiniApp and Web Applications are all of the web ecosystem. It will be more efficient if some features can be reused.

[dmurph]

@alancutter FYI about this discussion