Skip to content

Remove the zingolib submodule: ship one beta from the Prebuilt Bundles, then delete the submodule #1746

Closed

Description

@zancas

Where this stands

zingo-mobile takes the Binding Layer from the Prebuilt Bundles that the Bundle Pin names (zingo-adrs zingo-mobile/0020, zingolib/0059). The pin and the submodule both name 81d799775, zingolib v8.0.0, since #1836 moved them on 2026-10-29 (before it, #1745 moved them to the sixth entry 625f617b6, #1787 to v8.0.0-rc.0, #1829 to rc.1 and #1832 to rc.2). Every consumer builds from the fetched bundles, the nightlies included, and the two fetch jobs are required checks on dev since 2026-10-23. The submodule still exists, and the old build jobs still run with no consumer.

This issue asserts the next step for removing the zingolib submodule dependency. It supersedes #1728 and #1729. zingolib#2930 holds the plan, its rulings and its history; its steps 1 to 5 are done.

Done: one beta release from the bundles (zingolib#2930 step 5)

The release path needs the submodule for nothing. The tag-triggered Android release workflow assembles the APKs from the pinned AAR, and the keep-verifier reads the class list from that AAR. The proof is recorded in the comment below of 2026-11-02: betas 342, 343, 344 and 346 and stable 3.0.0 (324) were assembled from the pinned AAR at 81d799775, each run passing the assembly, the keep-verifier and the release creation, and users tested the betas through 346. Beta 345's run was cancelled and created no release.

Two items of the record are owed by whoever holds them: the Play and App Store Connect build numbers of the beta uploads, and the Mixnet Mode device test, one tester per platform, which proves the one iOS archive and the one mobile profile on a device. Neither gates step 6, since the stable release shipped from the same path.

Next step: delete the submodule (zingolib#2930 step 6)

One pull request deletes the submodule and everything that reaches into it: the two workflows that built the Binding Layer per platform and the workflow that derived their cache key, the action that checked the submodule out, the workflow that ran the Binding Layer's host-side tests (zingolib runs them since zingolib#2937), the action and the scripts that generated the Kotlin bindings on the host and their consumers, the two yarn scripts that built the Binding Layer, and every submodule reference in scripts and docs (the release quickstart still says the libraries build from the submodule). The same pull request updates the glossary, advances the ADR pointer, and moves zingo-adrs zingo-mobile/0020 to accepted and 0016 to superseded. As it merges, branch protection on dev drops the old build contexts and keeps the two fetch checks. Afterwards the LavaMoat stack (#1642, #1646, #1652) rebases onto dev, as ruled on 2026-10-21.

The deletion is #1865, opened 2026-11-02 from dev at 5fd3662, 27 files, +57/-951, with docs/adr advanced to a680cbe, the merge of zingo-adrs#63 (0020 accepted, 0016 superseded). The branch-protection rewrite is its first comment and runs as it merges.

Both of this step's preconditions are met: the dispatched CI nightly of 2026-10-23 passed every job that fetches, builds or installs the app from the bundles, and #1741 selects Xcode 26.3 in both jobs that build the app.

Rulings carried forward

Owed beside the sequence

  • zingo-adrs: the acceptance edits of zingolib/0059 and 0060 (0062 already reads accepted).
  • zingolib: the publisher App's pull-request write permission, so a publication opens its own record pull request.
  • kitchen-sync#8 moves to a current entry.

Updated 2026-11-02: step 5 is recorded as done; step 6 is #1865 with zingo-adrs#63 merged. Updated 2026-10-24: the pin moved to the sixth entry, 625f617b6, with #1745.

Activity

  1. zancas commented on Nov 2, 2026

    @zancas
    MemberAuthor

    Step 5 record

    Every Android release since the consumption merge was assembled from the pinned AAR. The pin and the submodule named 81d799775 (zingolib v8.0.0, pinned by #1836 as 2f86c7fba) at each tagged commit, under zingolib#2930 ruling 10. In each run the steps Assemble APKs (4 ABI splits + universal), Verify R8 kept the uniffi bindings and Create GitHub Release passed, and the release holds the five APKs.

    Tag Commit Run Result
    zingo-beta-3.0.0-342 ddba4d25a 40924669935 prerelease, 2026-10-29
    zingo-beta-3.0.0-343 c608186fc 40973358122 prerelease, 2026-10-29
    zingo-beta-3.0.0-344 2b6ecdbaf 40999269459 prerelease, 2026-10-30
    zingo-beta-3.0.0-345 e517ccd3b 41097521936 cancelled, no release
    zingo-beta-3.0.0-346 7ca7ec597 41215227041 prerelease, 2026-10-31
    zingo-3.0.0-324 5fd3662f3 41243706382 release, 2026-10-31

    Users tested the betas through 346, and the fixes they reported merged between them (#1833 to #1848). Stable 3.0.0 (324) shipped from the same path on 2026-10-31. The last release built from the submodule was 2.1.1 (323) on 2026-10-20, run 39496421890.

    Two items of step 5 are unrecorded here: the Play and App Store Connect build numbers of the beta uploads, and the Mixnet Mode device test, one tester per platform. Whoever uploaded the builds or ran the test adds them in a reply. The deletion of step 6 opens on this record.

  2. zancas commented on Nov 3, 2026

    @zancas
    MemberAuthor

    Step 6 is done. #1865 merged on 2026-11-03 as e1a38da after juanky201271's review. Branch protection on dev was rewritten before the merge and requires the 14 surviving contexts.

    Two pull requests follow it. #1866 deletes the residues the review found in the quickstarts, the scripts, four workflow checkouts, the ignore list, the Gradle source set and the lint suppression. #1868 restores the mixnet marker cross-check against zingolib at the pinned commit.

    Still owed beside this issue: the LavaMoat stack rebases onto dev, and the record above lacks the store build numbers and the Mixnet Mode device test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions