Hi,
Is there a microG update planned and for which /e/OS/ version ?
Latest version of microG includes QR codes scanning support, and this is a missing module to make my banking application work correctly.
Regain your privacy! Adopt /e/OS the deGoogled mobile OS and online services
Not in v3.0 as the code is already undergoing testing. But yes, it should be available in one of the future releases.
uh thanks, today-I-learned, those happened mid march
if you want to check if a change was imported into /e/OS microg repo and riding a specific release tag, copy over commit hash and replace any existing commit url picked from the list (they didn’t make it over yet).
Is it possible to update it manually, or would that break things in /e/OS?
Any changes upstream, be it in MicroG or LineageOS, have to be merged first into the /e/OS codebase. Next, we will run the changes against the /e/OS code for any compatibility issues. This takes some time, as you might expect.
Merging the code changes manually can result in bugs, and unless you are skilled at debugging and resolving issues yourself, it is advisable to wait for the development team to implement the changes.
Actually, I would only need to upgrade MicroG, activate the bank app, and downgrade MicroG back to /e/OS version. Would that be possible ?
I tried to upgrade MicroG through its F-droid repository, but it won’t install. Is there a process documented somewhere ?
Can’t be done unfortunately. (Or at least not without some nasty hacks to remove the /e/ version and replace it with the official upstream version.)
The problem is that /e/ have made their own fork of microG, rather than using the official upstream version. The /e/ fork will be signed with different keys than the official version so you cannot update the /e/ version with the official version from the microG web site or F-Droid repository.
This is another example of why forking - or worse, reimplementing - an app, component, or library, rather than using the upstream version - is almost always a mistake . For other examples of this, see the previously discussed problems with /e/'s forks and re-implementations of
In all these cases you may get the functionality or bug fixes you want, but they will probably be delayed significantly, and may not happen at all 
Thanks for clearing this up, it makes sense now!
Out of curiosity, considering these drawbacks, what do you think is the main motivation in murena’s case to develop these forks rather than to rely on the original packages?
Have one consistent UI and branding.
Have the Apps packaged with /e/OS inhouse to ensure compatibility and immediate bugfixing ability (ideally) as well as to soften development blows from upstream (radical or breaking changes, end of development).
What @mihi and @AnotherElk said. The consistent UI issue was the one given most priority in discussions at the time. The idea that bugs would be fixed quicker in the forks has clearly turned out to be wrong, with bugs persisting in the /e/ forks long after they were fixed upstream.