I wanted to flag a release structure issue that is causing friction for automated package managers like AppManager.
Currently, publishing both the Electron and Tauri desktop variants under the same version tag makes it difficult for tools to distinguish between them. This often results in the Tauri installation being accidentally overwritten by the Electron version during updates.
Is this about tags or about releases? Since both variants are build from the same git branch, would it work to simply have two tags pointing to the same commit?
Either way, this sounds like a hack. Monorepo projects are common, having different binaries is common. Look at Android, for example. We have separate builds for Google Play and for F-Droid, all built from the same commit.
I agree that managing two separate repositories for the same codebase would be a headache and overkill for the DeltaChat team.
At the same time, AppManager handles a large number of apps and needs standardized version-check logic to avoid complex per-project filtering rules.
I believe separate tags (e.g., desktop-v1.x and tauri-v1.x) pointing to the same commit would be a sufficient fix and a win-win. IIUC, this would also create separate GitHub Release entries, providing the distinct update paths needed for easy automation.
After checking with the AppManager dev, it seems there is a much better way that doesn’t require changing your release structure: adding zsync update info to the AppImages.
This would allow the files to be distinguished by their internal metadata.
If you’re open to looking into this, @Samueru-sama is also active there and might be able to provide further insight into the packaging details.
