Add Real versionName and versionCode to Android Package

[gigem]

In the Android package, the versionName is currently set to 1.0 and the versionCode is set to 1. The attached patch adds the real versionName to the package and adds a place holder versionCode. Suggestions on what to use for the versionCode are welcome. Some texts suggest <major> * 10000 + <minor> * 100 + <patch>. Currently, MythTV only uses <major> and <minor>.

Note that the patch assumes that android-package-source/AndroidManifest.xml is already git mv'd to android-package-source/AndroidManifest.xml.in. This is to avoid editing the source controlled, input version.

[Mark Spieth]

I'm not sure what the requirements are for versioning in submission to the play store. This may need to be researched.

OT: It is also a large apk compared with most and there is some text somewhere that says it may be too large.

Otherwise it looks ok. You cant have the .in file in android-package-source as it will deploy it too. Need a different tree for that.

[gigem]

I didn't see any requirements for versionName, though, I didn't really look. I got the impression the versionCode is what really matters to to Google and the Play Store. It's requirement is to be monotonically increasing.

Hmm, our package isn't that much larger than Kodi and that's with debug enabled. I suspect it could be considerably smaller with --comppile=type=release.

Okay. It's easy enough to move AndroidManifest.xml.in elsewhere.

[Peter Bennett]

Replying to gigem:

Suggestions on what to use for the versionCode are welcome. Some texts suggest <major> * 10000 + <minor> * 100 + <patch>. Currently, MythTV only uses <major> and <minor>.

I think we have to create multiple application names - MythTV29, MythTV30, MythTV31 etc., because we cannot expect everybody to be on the latest version.

That said, the version only has to be unique within MythTV30, MythTV31, etc.

Possibilities

• date and time built - yyyymmddhhmmss
• minor version code number * 1000 plus additional commit number from git describe. Minor version code number will have to be something like this
  • "-pre" = 00
  • "-rc1" = 01
  • "-rc2" = 02
  • ".0" = 10
  • ".1" = 11
  • ".2" = 12

Examples of second method

• v30-Pre-543-g697bf77 = MythTV30 version code 00543
• v29.1-9-g67e8d62 = MythTV29 version code 11009

[gigem]

I believe the versionCode is only really needed for apps distributed through the Play (or other) Store. I don't know what Google's requirements are beyond it being "monotonically increasing". I have doubts, however, that having a separate app, each with it's own versionCode space, would be acceptable.

Anyway, I think I'm going to punt on this issue for now by hardcoding the versionCode in mythtv/VERSION. We can address this issue when/if we ever try to get the app into the Play Store.

[gigem]

New patches for review.

[Mark Spieth]

• (2a) Perhaps it would be better to add MYTH_ANDROID_VERSION_CODE on the build command line (-D) so that it can be managed in the build system instead of the code, just like other packaging systems. Not sure of the consequences.

Otherwise looks good.

[gigem]

Since, AIUI, the versionCode is mainly for released versions, I wanted to put it as close to the real version handling as possible. However, our version name/number handling isn't terribly clear, so I just stuck it in mythversion.h for now. I don't feel strongly about it either way except that it should handled in such a way that isn't easily forgotten to be updated or used.

[Mark Spieth]

I don't know either. I just don't like versions in code.

Whatever you think is good enough.

[David Engel <david@…>]

In 6fe5e37f683cdbd39068502cb85b584b9dbce324/packaging:

Error: Processor CommitTicketReference failed

GIT backend not available