There is definitely no need to apologize. I appreciate the sentiment, but I included that information not to provoke sympathy, but to help draw a picture for the community - that decisions are having an effect and perhaps not a desired one. I do not know if we are the only people experiencing these kinds of issues, but I thought it might be of interest.
As for sharing, I definitely will be filing issues where appropriate. However, some of these issues are likely not serviceable as defects for the latest versions of the software. They are issues between existing versions of the software, or forms based on older versions of the software, which is unavoidable in long-term real-world deployments. I was trying to understand the philosophy towards ensuring stability for these types deployments, and perhaps through it, determine a better approach to maximize chances that things will not unexpectedly break over time. It seems like the project leans hard on the latest and greatest and stability over time takes a distant back seat. I want to check my assumptions before making a move.
I understand the moving pieces and that comes with any system. However, the concerning part of what I am seeing is that it appears like a pattern of conscious decision making. At a minimum, I want to raise that we are struggling a bit with those decisions over here. This likely is not the best mode to have a detailed conversation about it, so I will not dig into that here. The details are important on these and I will reach out help you resolve the specific issues we are experiencing.
I essentially wanted to get a sense of whether there is a better way of evaluating the risk of updating so we are not broken by what appears to be a minor release. I was hoping for something along the lines of: "Yes, we are using strict semantic versions: if the major version number is different, it's likely to include a breaking change. If only the minor versions is different, it is compatible and includes new features. If only the final number is different, no breaking or feature change is included - only defect fixes.". Another way to manage is LTS releases.
With regards to participation, I agree that the party experiencing issues (namely us this time) is in a prime position to help. In fact, that is why I am posting (I already investigated and deployed a working solution before sending this). I wanted to share that we are experiencing some pain under the existing process and decision making and it does not appear to be simply that things fell through the cracks; the specifics suggest that these things are being done knowingly and intentionally. Perhaps what we are attempting is at odds with the goals of the community, but I suspect that is not the case. It may be that some of the assumptions decision makers are operating under could use some adjustment. In that case, we might be able to offer some counter-examples.
My take-away from your response is that we will just need to devote more effort to ensure we don't get unexpectedly broken. Either being more involved in testing and informing development decisions, or perhaps spending more time evaluating updates. I should be direct with you. That seems like a heavy burden given our desire. We like what you released. We just want to make sure that the principle of least surprise applies over time. In other words, if we make a small change to a form and want to repeat the same process next year, we will not have to spend a surprising amount of resources and effort to do it. That is effectively what is happening to us again. We are fortunate to have resources to devote to doing this, but expecting development-time to ensure users can come back to their ODK-based workflows seems at odds with what I thought was a goal of the project - being a sustainable data collection tool.
I know it is not easy fielding this type of feedback and you should know that we appreciate what you are doing and thank you all for making ODK what it is - you know who you are. We love what you made and are making, we want to keep running it and contributing back what we can.
Thank you for always fielding the challenging ones Yaw.