| 16 Nov 2018 |
 _hc | fdroid update totally ignores Builds: | 17:20:29 |
| _hc | it just parses the APKs that are present for package entries | 17:20:51 |
 Marcus (old) | It certainly acts on disabled= | 17:20:52 |
| _hc | nope | 17:21:00 |
| Marcus (old) | huh? | 17:21:10 |
| _hc | well, the archiving part does | 17:21:16 |
| _hc | not the index gen part | 17:21:23 |
| _hc | the wiki updating also looks at Builds: | 17:22:04 |
| Marcus (old) | hm. I generally like just having something like a build template recipe in the metadata files | 17:22:32 |
| _hc | ah, index-v0 looks at versionCode/versionName in the builds | 17:22:49 |
| Marcus (old) | and actually having older versions of this in the git history | 17:22:51 |
| Marcus (old) | but I guess that's a fairly major change | 17:23:36 |
| Marcus (old) | because a bunch of places will still use the enrties | 17:23:52 |
| _hc | so index gen only checks the builds for a versionName if the versionName can't be parsed from the APK | 17:23:54 |
| _hc | and that code can already handle it if vesrionName is not in the metadata's build entry | 17:25:40 |
| _hc | update.delete_disabled_builds() needs build.versionCode | 17:27:24 |
| _hc | so disabled: would require versionCode: | 17:27:55 |
| _hc | so it can gen the filename to delete | 17:28:14 |
| _hc | fdroid update will read antifeatures: from Builds entries if they are present, then include that in the index | 17:29:30 |
| _hc | so setting a per-APK antifeature different from the previuos APK will require a new build entry | 17:29:58 |
| _hc | flavour-specific fastlane/tripleT files already look for the gradle flavor in the most recent build entry | 17:31:27 |
| _hc | to specify a gradle flavour, there needs to be at least one build entry | 17:32:03 |
| _hc | and that's all I can see. so it seems totally feasble to me to allow operations without Builds: that just goes entirely on Tags | 17:32:44 |
| _hc | then certain features require per-APK entries | 17:33:22 |
|  hobbes left the room. | 17:36:48 |
 Tovok7 | also need to think about what happens when a new build breaks, because changes are needed. does this get logged to the wiki? | 17:37:19 |
|  perepujal joined the room. | 17:37:29 |
|  asafniv joined the room. | 17:38:17 |
| _hc | yeah, all builds should be logged to the wiki | 17:39:07 |
| _hc | uniq already implemented saving a plain text build log that can be deployed via rsync to the website, CiaranG would have to enable that | 17:39:50 |
