Hi @wroos,
At least giving option to chose either current or old form to use would be preferable.
Thanks for the suggestion.
In general, we fully agree with your suggestion - and we would appreciate getting early information (roadmap) about such structural changes planned by the development team.
We’ve introduced public beta testing of Enketo releases—and having seen new releases break your advanced use cases was a big motivator for that—but we haven’t yet had the resources to launch a public beta program for the rest of the application. We’re working on it.
We did not publish the release notes in advance of the release because the release included a security fix. We wanted the security issue to be rectified on our servers before disclosing in such an obvious way. The edit change was actually part of the security fix: we moved editing from KoBoCAT to KPI, and by doing so (which was not a small effort), we gained the ability to control which version of the form is used for editing. Yes, we could have left the behavior as it was, where editing always used the latest version of the form, and perhaps we should have done that until a subsequent release. However, people have been after us for years to make Enketo open submissions using the “correct” version of the form, by which they meant the version in use when the data was collected. It was never something we could prioritize given other obligations, but when auditors revealed the security issue, we had no choice but to pour time into retooling editing. Correcting the version “problem” (as many viewed it) was easy once we had already undertaken all that work.
A roadmap will not include fixes for security issues that are discovered unexpectedly, nor would I expect to include bug fixes, which is what I considered the version change based on all the complaints we’d received in the past. Obviously, I’m now dealing with at least two very unhappy people and can certainly understand now why you would’ve liked advance notice. I think the public beta will be the best way forward: that way, avoiding these situations won’t hinge on me subjectively making the right decision as to what should be published in advance with enough fanfare for everyone to notice.
@emreozkan90, you have, of course, every right to be frustrated with a change we’ve made that disrupts your workflow. However, your conduct here is exceedingly disheartening. I will note for the record that absolutely zero business days have passed since you raised this issue here or in the other topic where you posted initially. I’m truly baffled as to how you think SHOUTING, threatening, and disparaging the staff that works hard to provide you with a free service will move anything forward in a productive way. Seriously consider another manner of communication. Please.
John Milner
Lead Developer
KoboToolbox
…writing on a Saturday, at 11 am local time.
