[Desktop] Even in beta, desktop needs versions

Steps to reproduce

Attempt to build versioned packages for linux distributions

Expected result

Release a new package when an updated version is released, even in beta

Actual result

Release artifacts are indistinguishable from one another from end user/downloader perspective until downloaded and extracted.

Environment

RPM, deb, emerge, apk, pacman based distros (or any other that need versioned artifacts)


Additional information

Once this is rectified I’ll be happy to build and maintain a release for archlinux.

https://aur.archlinux.org/packages/dynalist-desktop/

cc @Shida

Hmm… We internally use an auto-updater system that updates just the resource files needed to run Dynalist (HTML, JS, CSS, etc) every time we make a deployment. This is why the executable we provide are at version 1.0.2 but inside the app it shows 1.0.31 once the dynalist resource package is auto-updated.

I’m not sure how this would work with linux artifacts. Any ideas?

Interesting. I think this is typical for electron type apps, wrgt auto-updates. I think others solve this by also releasing an updated executable with any versioned releases that would be otherwise installed via the auto-updater. The best way would be to automate the executable build and release cycle along side the build and release of your application code (resource package) and version the tarball name as well as the directory name within the archive. For now it sounds like the archlinux package I’ve created will continue to work but will likely get flagged as out of date by the archlinux community (due to the release package version) even though it auto-updates. Other distros would likely have similar issues. When you can it would be really nice to put versioned executable releases into your CI pipeline :wink:

Thanks! Pretty sure I’ll be subscribing once my trial is up.

The reason why we really like our current system is because our resource pack is about 10MB gzipped, whereas the full package is around 53MB gzipped, which includes the 10MB resource pack. So that’s 43 MB for each version release that has not changed whatsoever.

When you say “[it gets] flagged as out of date”, is it a manual process (a user manually flags it out of date), or some kind of automatic “hasn’t updated for x weeks” process?

Yup, I totally understand the desire for small release artifacts. I don’t think these concerns negate one another though. Couldn’t you continue your “resource pack” releases as you do now, just add an automated process to update your executable to include the new resource pack. This way, any new “download” of the executable will already include the latest resource pack, but those who don’t download a new exe will continue to get the standard auto-updates. This would make both end users and linux distribution package maintainers happy.

Yes, the flagging is a manual process undertaken by interested, but maybe not informed, end users of a package. You will see a link on this page labeled “Flag package as out-of-date” that is the exact flagging feature I mentioned:
https://aur.archlinux.org/packages/dynalist-desktop/

To be clear, dynalist desktop is working perfectly in archlinux as is, so you really don’t need to take any action on this today. However, as you gain traction, I suspect you will not see the end of this request as more package maintainers attempt to package dynalist for their distro of choice.

Ah I see. That helps me understand a lot better. We might be able to support that in the future when we re-work our desktop app’s build pipeline.

For now, when we deploy a full downloadable version, we do that for all platforms we support, which ends up with 5 packages (win-32, win-64, mac, linux-32, linux64), each between 50MB and 60MB to be uploaded to the server, and each of which takes quite some time to build and sign. This would make the deploy time around 1 hour plus whatever it takes to upload, whereas our resource pack takes about 5 minutes to build and upload.

The other complication is that each platform’s build runs in a VM, so we’d have to spin those up, import our latest code, build, then export it back out. In contrast, our resource pack only needs to be built once and is compatible with every platform.

1 Like