Dear Community!
We are always working hard to improve QField and add exciting new features. However, we are dedicating our next release to something just as important as innovation: stability and polishing.
For an entire release cycle, our developers will focus exclusively on fixing bugs and fine-tuning existing features.
To make our next release: QField 4.3 “Summer of Stability” (planned for late August), a complete success, we need your support!
Please share any reproducible bugs, including clear steps to reproduce and sample projects, with us directly on GitHub!
Issues · opengisch/QField · GitHub
Thank you for being part of this exciting period and for helping us make QField even better, together! 
Cheers
The QField Team
@MsAllroundata Great to hear!
To be honest, the stability of QField is a huge struggle for our fieldworkers. Who are not always the best with digital systems.
For us as GIS specialists, the large amount of release are difficult to handle. It happened quite a few times that functionalities of our projects were negatively affected by new releases. Therefore, our policy is not to automatically update QField. We test the release with our projects before the fieldworkers may update QField.
This lead to our next issue. QField has a high rate of releases with bug fixes. It would be great if the stability of releases would be improved and amount of bug fixes needed will be less. So, the rate of new releases will be lower.
Thanks for your hard work! Have a great summer!
@ckuipersatkb I tend to agree with this opinion, maybe a toggle on the app to choose between “nightly/bleeding edge” and “stable/lts” branches of updates might be useful. For personal use, I do prefer to see what’s new as soon as possible, but wholeheartedly agree that might not be the best approach in general for organisations.
Although in a way, I feel like QField already provides such separated channels, in the form of the official public release on one side, for “enthusiasts” and as a default option to help drive the development and ironing out of bugs and features. And on the other side, the ability to clone and fork both the app and the server software, allowing organisations to manage and pull the updates as they see fit. To me this seems fair and reasonable, since they also provide support services for specific needs.
Perhaps lots of issues arises on a, arguably quite large, middle zone of small/resource-constrained/lean organisations that go away without much supporting roles such as IT departments and often rely on BYOD kind of strategies, resulting in a clash of expectations. Maybe there is an opportunity in there for another product or solution (probably from QField themselves), but I’m not sure.
We also are releasing the master release every day on the play store for enthusiasts.
Managing a separated slower release channel would come with its big set of drawbacks for the development. So it is not a high priority for now but we have definitely an open ear. For now the summer of stability is aimed exactly at that.
I am not sure if I am familiar with this option. We install QField from the playstore with the “auto-updates” turned off. Sometime we use the apk-files from GitHub when necessary.
There is another channel?
I mean primarily the GitHub Pages of Opengis.ch, that include both the QField app and the QFieldCloud source codes. On each respective page, you do have all the different versions of the software available for download, but you can also just fork, clone and do all the things that Git enables to see and manage all the source code changes that come up and compile your own version of these software.
What I meant was that I think organisations should probably not rely on default public repositories in general (such as the play store), as a good practice. But rather they should prefer to manage private internal repositories of the tools they depend on, to have predictable and controlled output. In that regard, QField is excellent since it’s open source and available through an easy to use public repository such as github, so you can check every single line of code changed before committing to an update if you so choose. Of course, this ideally requires a dedicated person or team to manage and compile the code and the organisation’s internal repository.