@teleivo, interesting comments!
Right now, as we’re working on the release for Reference Application 2.5, we need to release a lot of individual modules. I presume that any recent releases are driven by this.
I actually think we want the opposite of this.
In my experience the most feasible way for multiple groups to collaborate on an OpenMRS module, without slowing down their on the ground work, is if we make “module version release” is a small thing you should expect to potentially happen often and unexpectedly (as long as we correctly increment the major release version as needed). And this aligns with the Continuous Deployment philosophy: lots of small releases, and be ready to do them at any moment.
E.g. PIH, Bahmni, and the Refapp teams have all contributed to the emrapi module, and when one of them needs a release with a fixed version to deploy to prod, they do a release. (And I speculate if they had to follow a slower process, someone would have had to fork…)
So, I think that specific module versions are unimportant, but I think that having a module roadmap is important, and 95% of modules don’t have one. Any thoughts about how we might achieve this?