Why the versionName is 2.0.0? about bubblewrap HOT 5 CLOSED

That's a left-over from svgomg-twa, which was used as a base for the template. We can reset that back to 1.0.0.

Nevertheless, we need a mechanism to enable #3, where versionCode and versionName are updated with the template.

One option is to control this via the template. We'd have to bump versionName and versionCode on the template when it's changed, and update would apply the new template.

The second option (somewhat my preferred, is to save the current versionCode and versionName to twa-manifest.json and bump it when llama-pack update is invoked. We'd still probably want to have a way to track template versions, for debugging purposes.

from bubblewrap.

versionCode is the bit that really matters on the Play Store, and the number must always go up between versions. I think we can just have the 2 values on the twa-manifest and update them independently. eg:

...
"version": {
    "code": 1,
    "name": "1.0.0"
} 
...

from bubblewrap.

Moving the conversation on how to update versions to #74 and closing this issue, as resetting the versionName has been implemented on #71.

from bubblewrap.

Reading about Versioning Android apps here...

What do you think of having a version field in the manifest?
And let the build.gradle generate versionCode and versionName.

Something like:

...
"version": "2.3.1",
...

And then the build.gradle generates:

versionCode 20301
versionName "2.3.1"

(ignoring the API level and screen sizes from the post)

Then the user just need to update the application version in the manifest in a semantic version way.

To calculate the versionCode:

const versionCode = (majorVersion * 10000) + (minorVersion * 100) + patchVersion;

from bubblewrap.

Yes, but following a formula like this, the versionCode would always increase:

const versionCode = (majorVersion * 10000) + (minorVersion * 100) + patchVersion;

So a version like "2.3.1" generates the version code 20301.

But having both options also works. 👍

from bubblewrap.