[Tracker] Update the GitHub release pipeline

[M123-dev]

Why

• Now that the app is release it's time to rework our release piplines
• The most important parts about it are:
  • We want a private listing for testing and a public listing to be able to use the app and debug on the same device
  • Currently we don't have a real strategy for version names
  • We have no way to find out which commit is in which release
  • We need different builds, namely iOS, Android, FDroid

What

• We decided on a new release process in a meeting
• Explained very simple:
  • Every commit should go to the private internal listing
  • Every release (triggered by release-please) should go to beta and should be promoted to public manually

Other steps to do are

• Tag every release to have more information
• Assure that all versions have the same name + code for tools like sentry
• Create a Github release on every main release (planned weekly)
• Modularize the release workflow to work avoid duplication as best as possible
• Create releases by merging release-please
• Don't fail CI on codecov failure
• Create different flavours (not available) for different releases
• Create a different store listing for the internal variant
• Make the internal test variant distinguishable from the normal build (maybe https://docs.fastlane.tools/actions/badge/)
• Make the internal test variant distinguishable in sentry + matomo
• Fix the iOS duplicate version code problem
• Check if the iOS sentry cocoapods problem is fixed
• Upload the APK to the Github releases
• Create FDroid version and create dedicated release (Running on F-Droid's side, not github actions)
• Create and serve Amazon Store listing
• Don't break everything
• Open iOS release train iOS release failing #2745

Other automation tasks not related to release

• Check if the example product is up to date
• Automatically download and update assets
• Image optimization

Related to

• Use Sentry to its fullest #2749

[natrius]

Upload the APK to the Github releases

Do i miss something or should there be an apk here to download? https://github.com/openfoodfacts/smooth-app/releases

[M123-dev]

Heyyy @natrius good catch, yeah there should be, I just ticked this box 2 days ago. When we merge #3159 then there will be an apk to download

[M123-dev]

The Zxing implementation is now merged.

@Altonss @natrius you seem to be interested in FDroid, do you know how to properly release it on there. AFAIK we can't to that here but have to write a script which builds on FDroid servers, is that correct?

Also another interesting question is whether we should force update the current FDroid folks or not, I would say that these are the people who are the likeliest to complain about it.

Also for historical reasons the FDroid listing has a different package name.

@VaiTon what do you say about this?

[Altonss]

@Altonss @natrius you seem to be interested in FDroid, do you know how to properly release it on there. AFAIK we can't to that here but have to write a script which builds on FDroid servers, is that correct?

To update the existing app, we should just update the build recipe https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/openfoodfacts.github.scrachx.openfood.yml (and the metadata)

[Altonss]

As the old app isn't maintained anymore, I'm not sure about having to separate apps (the new and the old unmaintained...).
Maybe @IzzySoft has an idea :)

[IzzySoft]

If the old app is abandoned, the new app intended to replace it, authorship is identical, applicationId is kept: yes, simply update the metadata to point to the new repo (and if needed, adjust the build recipe by inserting its "build block" for the first new release). Otherwise: new app, mentioning being the successor – and if possible inject a hint to the description of the old app to point to its successor (to hopefully make existing users aware of the change).

[M123-dev]

Okay so the question is to which degree the old app is maintained, I am checking that

[VaiTon]

Hey! The old app is not abandoned, but I think the majority of F-Droid users would want to use this app, so I'd put the old app as a new listing (maybe "classic" or something like that) and update the actual listing to this app.

Actually I'm a bit overloaded in maintaining the old app as I'm almost the only one making changes and I do not have a lot of time atm.

The classic listing could be also done in the future, it's not very urgent.

[M123-dev]

Thanks for the answer @VaiTon so we can override the new listing.

We need to:

• Check that we can update the package name (old: openfoodfacts.github.scrachx.openfood, new: org.openfoodfacts.scanner
• Use flutter for building (example https://gitlab.com/fdroid/fdroiddata/blob/master/metadata/com.nikhiljha.lobstersapp.yml)
• Create a new build on every new github release
• We ask for permission to track behaviour & crashes in the onboarding, we have to check if thats fine or marked as a unwanted trait

[IzzySoft]

I'd put the old app as a new listing (maybe "classic" or something like that) and update the actual listing to this app.

Up to you of course, but wouldn't that be a little confusing: a new app being the old app, and the old app suddenly being another app? Alternative would be introducing the new app as new app, and push a minor update to the old one to introduce a hint to ① its description and maybe ② a little hint on its next start, pointing to the new app?

I didn't check, but it (thanks to Flutter) the new app suddenly is 3 times the size, just "pushing it" onto those having the old one installed… ahem… especially maybe on some low-end devices this might not exactly produce a "good experience" 😉

Ack to the other points ­hopefully you've chosen a FOSS crash reporter (again, I did not check – so roll-eyes justified in case you did 🙈)

[natrius]

and push a minor update to the old one to introduce a hint to ① its description and maybe ② a little hint on its next start, pointing to the new app?

A major update on the old one is needed anyway because the current version is absolutely broken :D

[IzzySoft]

Eh 🤷‍♂️ In that case… why then revive it using a different name at all? If it gets fixed, it should IMHO be under its current name. But I won't argue further, it's the decision of its authors. I just wanted to share my 2 ct 😉

[M123-dev]

Honestly I would prefer a new listing to avoid handling around with a different package name, it's already interesting to have different flavours for PlayStore and FDroid as well as iOS and in future also listings in other stores.

This way we can keep the old listing, maybe fix the release, push the latest version with a hint that we have published a new app cc @VaiTon

But lets wait for what @teolemon & @stephanegigandet think about that

[M123-dev]

By the way @natrius we now have a apk in the latest github release https://github.com/openfoodfacts/smooth-app/releases/tag/v4.0.0

[M123-dev]

In todays community meeting we decided to go with a new listing instead of force updating the old one.
Is anyone here interested in helping with that?

Also cc: @licaon-kter not specifically for that, more for this whole thread, I heard you had large impact on the F-Droid release on the native app.

[licaon-kter]

First thing, it's spelled F-Droid 🙂

Now... this recipe: metadata/org.openfoodfacts.scanner.yml

License: Unknown
SourceCode: https://github.com/openfoodfacts/smooth-app
IssueTracker: https://github.com/openfoodfacts/smooth-app/issues

RepoType: git
Repo: https://github.com/openfoodfacts/smooth-app.git

Builds:
  - versionName: 0.0.0
    versionCode: 600
    commit: v4.0.0
    subdir: packages/app
    output: build/app/outputs/flutter-apk/app-release.apk
    srclibs:
      - flutter@3.0.5
    rm:
      - packages/app/ios
      - packages/app/linux
      - packages/app/macos
      - packages/app/web
      - packages/app/windows
    build:
      - $$flutter$$/bin/flutter config --no-analytics
      - $$flutter$$/bin/flutter pub get
      - $$flutter$$/bin/flutter pub remove scanner_mlkit
      - $$flutter$$/bin/flutter build apk

AutoUpdateMode: None
UpdateCheckMode: Tags

Fails to build: org.openfoodfacts.scanner_600.log.gz

Of note also, version is not set https://github.com/openfoodfacts/smooth-app/blob/develop/packages/app/pubspec.yaml#L3 it should be version: versionName+versionCode so we can enable autoupdate.

And pls setup flutter as a git submodule, that way you can bump gradle to whatever version you want in the future and there's no need to manually edit the recipe on F-Droid's side.