Reminder: The terms of service apply here too.
Logo design credit goes to: tubbadu
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.
Non-technical explanation: because they can.
Financial explanation: Because it's cheaper to have all your users as involuntary testers, than to actually ensure app quality in-house.
Continuous deployment pipelines usually have lots of automatic testing ensuring nothing breaks for the user.
"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.
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.
QA is not a capitalizable expense or something anyways that's why we havent given you a decent raise since you got promoted
Now get back to working your 3 jobs you software engineering qa testing devops piece of ..... valued member of the team
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.
Big releases are harder to test and debug issues.
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.
What would be best? Dealing with a bug for 1 month waiting a monthly update, or dealing with a bug 2 days waiting a daily update?
That depends only on your ratio of:
Fixed bugs / New bugs
:-)
If you’re doing a daily release with a net increase of bugs, you’re gonna stop doing daily releases real soon.
You clearly don't work for Microsoft
How about bugfixes every day if there are any, new features every month when they have been tested and QAd.
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.
Oh LTS. Absolutely. Great point.
The real answee is CI/CD DevOps pipelines.
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.
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?
Because Im not a beta tester, and understand that the fastest way to make a bug is to patch a different one.
I dont think this question should be in no stupid questions, but I am curious about a paired sub about answers.
If you aren't an alpha/beta tester then why would you want that?
My naive butt: "I thought Google and Apple reviewed app applications for malicious code" Older me: "bahahahahaha" cries in cyber security
Because they either don't do QA or think automated tests are sufficient
It's interesting that every time I open Voyager I see an update warnin
It means that these apps have extremely patiently suffering users :-)
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