What this means is that, when I as a developer push changes to my dev branch in my code repository, a bunch of scripts and stuff automatically test my code for a bunch of things, and if all of those tests pass, another script is run that pushes the code to my main branch and then compiles my app from the main code, and finally the last script pushes the compiled “artefact” out to the public (.exe’s out on a webpage to download, a linux package gets pushed out to repos and to Flathub, Android apps get pushed to the Play and/or F-Droid stores, Apple stuff gets sent to an Apple computer and compiled and uploaded to the App store, etc.)
It streamlines the development process and makes life on the developer so, so much easier while making sure bugs also get fixed for users much quicker and the app stays more stable.
If your release contains a single change and something goes wrong, you’ve got a pretty good idea of where the problem is before you even start to look.
If the friction of creating a release is low (with automated tooling) and updating is (typically) automatic there’s not really a good reason to not release as often as possible in most cases.
It’s a very nice thing to have, but I do worry about the effect this has on the EMMC storage in mobile devices, which has a finite lifetime - particularly for larger cross-platform apps, seeing as two of my previous android devices failed from worn out EMMC.
At the moment I just check F-Droid notifications and manually update each app on a biweekly basis, unless there’s an urgent fix or something
Some apps are a community effort with multiple contributors. Voyager is one of those. This may have been better asked in no stupid questions. Why would you not want the latest bug fixes and features immediately after they’ve been approved?
It’s not required, it’s really a matter of preference. Many users, me included, prefer having access to the newest features and bug fixes right away, but that also means less time to test the code for new bugs.
For another example, look at Debian vs. Arch Linux and how they are released
That’s a really good example. Also makes me think of apps that have stable and beta/nightly builds available. Stable gets updated at a much slower pace than beta/nightly.
Came here to point that out. You also have LTS versions for business critical software. Sometimes, a newer version is in beta or nightly mode for a long time while the stable version only receives bug fixes.
It’s agile. Every change is small and less likely to break the overall experience. Putting into hands of users quickly means bugs, especially breaking bugs are found quickly and easily backed out or fixed. If you wait a month, then when a bug is reported it’s much harder to track down and fix. Plus your users suffer until your next release.
Because someone in the dev team had the time to hook up their continuous integration scripts with Play Store publishing API, to the despair and jealosity of dev teams of all other apps.
This is how software should be managed. You make a change to your software, push one extra button, and in one hour all your users receive it.
In case of open-source projects like Fairemail, your budget is very likely zero or in negatives. Very often it’s one or few developers who make the app basically for their own daily use, and publish it on a ‘use at your own risk’ basis for everyone else. So yeah, if you use any open-source software, please do some testing work if you want it to improve.
“usually” is very generous. Automated testing takes effort to develop and maintain, a lot more than the rest of the CICD pipeline combined. And it’s only one piece of a complete qa strategy, if it’s all you have you’re still using users as testers.
Add comment