While I welcome the monthly publication of new releases of the various ODK software components, these constant and rapid changes do pose problems for regular users. Indeed, we often have to re-train staff to adapt to these constant changes.
I therefore call on the ODK community and developers to adopt a strategy similar to QGIS and publish a yearly 'fully tested and stable' "Long Term Release (LTR)" version, with bug fixes releases when needed but without feature changes. This LTR would be used in production environments.
Of course the monthly version should continue for testing of new features and for those who are eager to use new features soonest.
This is a very interesting idea, and one I've thought about with other products/platforms in the past.
I've always wondered how this would work when folks are downloading apps through venues like the Google Play Store. I know it's possible to get on a "fast track" beta release kind of thing there, but is it possible to do the reverse and get on a more stable release in the same way?
@Souirji_Abdelghani Thanks for all your contributions on the forum so far and for bringing up this important issue!
Our goal in the short term with Collect has been to update underlying libraries, fix bugs, and add long-requested features with minimal user impact.
I think we've done a decent job so far. Active installs are up and crashes are down. And when we've been told about a bug in a release, we've been able to fix it in a day or so.
You are correct that there are sometimes changes that require re-training and I know that can require a lot of work your part. That's a problem for sure, but before we make a change in the process, it'd be good to understand how big of a problem this has been for you.
Is there a specific example of a change we made that required re-training (e.g., the change in the date/time widgets)?
How much work was the retraining? Minutes? Hours? Days?
Is the change something you would have caught in our beta program that ships betas one week before the production release?
In general, we've tried to ask feedback on the forum about changes that might be disruptive but we haven't had much response. We want to do more there, so if you have ideas on how we could do that better, please do include that in your response.
There is no notion of a stable channel on the Play Store, but we do have APKs for download on the ODK website that folks can use if they want to be on a particular release.
Dear @yanokwa,
The ODK team has done a great job so far and there is no question that it has been very reactive and efficient and bugs get resolved quickly and requested features get added quite rapidly. This situation is great and I'm certainly not complaining at all.
However, production environments need some stability and constant changes (not bug fixes!) are annoying and may make the teaching/learning process more arduous.
I said in my communication that "Indeed, we often have to re-train staff to adapt to these constant changes". It would have been more accurate for me to say "Indeed, this may require re-training of staff ....". It is a fear I get from reading in the forum and github the rapid evolution of the ODK suite.
Having trained people in QGIS, I have found the LTR versions very useful and provide a relatively stable learning environment. This month I shall give a first ODK training to a host of trainees in Ethiopia and I have prepared everything with the versions available in April 2017. I would appreciate, if at all possible, to use LTR versions of the ODK suite for training and production environment with the same philosophy that exists for QGIS and other software.
I my opinion, the app stores should supply only 'stable' LTR versions and their bug fixes updates. The time that elapses between the existing beta versions (beta program) and the monthly releases is too short to carry out full testing. Therefore, the monthly releases are still 'beta' to a certain extent. It seems to me important to distinguish the full production environment from the beta (1, 2, ...) testing one.
This is just a contribution to raise a legitimate question for a trainer and a production user. It is by no mean a criticism of the fantastic work accomplished everyday by the ODK team.
I think our current priority should be moving quickly but safely to stabilize the codebase and add minimally disruptive features that keep folks excited about using ODK. Once we have that in place, I think we can then have a broader conversation about how to best to provide bigger features but with some stability. Maybe that’s via quarterly releases instead of monthly. Maybe that’s via LTR.
Until then, we do need help minimizing user impact! One way you can help is by following the milestones we've laid out https://github.com/opendatakit/collect/milestones and offering feedback each month. We have plans for a more long-term roadmap and we’d love to include you (and anyone else who is reading this topic) in those discussions. We'll put a call out in Community when that process starts.
As far as the beta program, it was our goal that it’d take less than an hour for users to verify the changes and offer feedback. We try to put the areas of change in the release notes, but maybe we could also include a protocol to help guide those tests. Do you think that would help reduce the test burden?
Finally, I'm very interested to hear how the training in Ethiopia goes! Will you be able to share your findings with the community?
Thanks for your thoughtful remarks. I do understand that since there are now rapid new features additions, it is better to wait for some time when the code base has somewhat stabilized, before introducing either LTR versions or slow down the release rhythm.
This makes sense and I am glad you envisage this solution.
I shall happily share with you and the community about the training unfolding and results ASAP.
@yanokwa Just to chip in on the beta program - in our case, testing a new release every month (even if it's only intended to be about 1 hour) seems a bit intensive (note: I'm not saying that it is, just that we perceive it as a task that takes some effort). Currently we don't engage with the beta and hope everything turns out ok!
If releases do drop down to every quarter instead of every month we might be more inclined to test the beta releases with our forms.
But monthly releases of bug-fixes are useful and needed, especially where community members have submitted fixes to issues they've encountered - they wouldn't want to wait another 2 months for fixes to be released via the Play Store.
I support the idea of a LTS/LTR version, but do understand the need for some sort of measure of impact before deploying resources onto it.
I see that CommCare has a LTS version on the Play Store - may be worth asking them for inputs on how they handle that.
We've only had one problem with an app update causing problems in the past, but that was fixed with a re-install of Collect (it affected already-downloaded forms, not fresh downloads of the forms), and the bug was fixed a day or two later.