WIP: add sensible defaults to the build metadata
This adds a new
AutoUpdateMode: to base updates purely on git tags. This also makes
Builds: entries optional. If an app has git release tags and works with the defaults, then no
Builds: entries would be needed. This does not mean that have to leave out the
Builds: entries. They can still be added and everything will work as before.
Most of the time, each entry in
Builds: is the same exact thing as the previous, minus versionCode/versionName/commit diffs. So if commit is auto-defined as the git tag
and versionCode/versionName is optional #387, then most build entries are purely redundant. They do provide a permanent record of releases that were tried, e.g. if upstream deletes tags. The archived APKs, source tarballs, and build logs also provide that info.
Repo:if it is github or gitlab
commit:defaults to one per git tag
gradle: yesis build.gradle is present at the root
commit:is not set
subdir: appif it is a gradle build and app/ is present
- read versionName and versionCode from APK if left blank
These are the only other uses of
Builds: entries that I could find:
fdroid updateonly uses limited bits of the
Builds:entries. When generating the index,
fdroid updateonly checks the builds for a versionName if the versionName can't be parsed from the APK. That code can already handle if versionName is not in the metadata file's build entry.
- If someone needs to disable one APK, then a
Builds:entry is required.
update.delete_disabled_builds()needs versionCode so it can generate the filename to delete.
fdroid updatewill read antifeatures from
Builds:entries if they are present, then include that in the index. So setting a per-APK anti-feature different from the previous APK will require a new build entry.
- Flavour-specific fastlane/tripleT files already look for the gradle flavour in the most recent
Builds:entry, so only one entry is needed to support gradle flavours.
fdroid lintalready handles missing build.commit, and doesn't use build.subdir or build.gradle. versionName/versionCode need to be handled
More discussion here in #fdroid: https://matrix.to/#/!HwocBmCtBcHQhILtYQ:matrix.org/$1542381676609448UANNL:matrix.org