As all of you are aware we are standardizing the release process and agreed to release OpenMRS Platform once a year and OpenMRS 2.x/Reference Application twice a year.
But, the whole release process is usually very rushed and is leading to some delays.
I would like to propose standardizing the release process further in one of the aspect and set a timeline for the OpenMRS 2.x/Reference Application initially as that might help things become simpler (with help from @michael )
8 months ahead: Selecting a Release manager and let the release manager monitor one release before they begin their release.
3 months ahead: Release manager announces the list of modules being released and starts monitoring them. Gets all the permissions and accounts setup needed for the release process.
2 months ahead: Stop coding/accepting pull request the release.
1.5 month ahead: Release all required modules.
1 month ahead: Setup Testing environment.
15 days ahead: Focus on issues arising in the testing period and also any critical issues that needs to be fixed.
There might be some changes depending on each release.
@maurya, this sounds like a terrific plan. The most important ingredient (besides the plan itself) will be someone owning the process. For example, who is ensuring that these targets are met?
@jthomas could probably take milestones like you’ve outlined and turn them into reminders. For the Reference Application, it’s simpler, since we know we want to release each March & September. Based on your proposed schedule, it would look something like this:
Early January: Select release manager for September release. March release manager announces modules.
Mid January: Code freeze for March release.
Early February: Release all required modules for March release.
Mid February: Set up UAT for March release
Early March: Address any issues from UAT for March release
Early June: September release manager announces modules.
July: Select release manager for next March release. Code freeze for September release.
Early August: Release all required modules for September release.
Mid August: Set up UAT for September release.
Early September: address any issues from UAT for September release.
But what we could really use is a “Release Manager Manager” – i.e., someone who wakes up thinking about how well we’re doing with releases as a community and defines & pushes us toward goals in improving release management. We’ve considered the role for “Release Magement” in the draft of OpenMRS Community Roles, but how & where could we find someone to fill it? Can you think of anyone who would be willing to wear that hat?
@maurya the plan looks good to me and i actually think given your experience, to me you are in the best position to assume the release management role.
Let me highlight one thing: the primary underlying reason that our releases usually lag behind is that we haven’t truly accepted the main implication that come from
(a) committing to release on a schedule rather than by a feature set
(b) not having much reliably-dedicated developer time.
Your proposed timeline is good, however the reason we haven’t historically followed something like that for at least 2.2 and 2.3 is that there has been a way-too-optimistic roadmap set out ahead of time, and we say to ourselves “let’s wait until more of this is done”.
I think we should shift our communal mindset, and commit to the idea that releases will happen on schedule even if they don’t include any end-user-visible features, but merely by including the latest released versions of modules.
But let’s be explicit: if we had followed that path with the upcoming Reference Application 2.3, that would have meant bumping the Admin UI module to a later release, and releasing with literally zero of the top-level features from our initial 2.3 roadmap. (Personally I think this is the right way to go, but I want us to be clear about the implications.)
Also…
The reference application releases don’t work like openmrs-core releases, because we don’t have release branches for all the modules in the distro, so there’s no practical way to “stop coding/accepting pull requests.”
I think it needs to go more like
2 months ahead: all module developers must start getting their modules into a releasable state (refapp modules are always supposed to be “releasable”, but this must be specially enforced from this point until the final release)
1.5 months ahead: Release all required modules (really we need to give a specific time span where this will happen)
It’s also important for people building other OpenMRS distributions (e.g. PIH, Bahmni) to comment on how this will affect their workflows.
Hi @maurya
Thanks for bringing this up. Based on your timeline, I’m almost on schedule
I agree with @burke’s idea of filling up the Release Management position with someone with prior of the Release Process. As I am a new recruit, I think it would be good to have a dedicated person to approach to with any questions regarding the release process.
I must confess that someone can easily think a Release Manager is responsible for all the releases that we come up with, even when it is for a specific release. This would be a good idea
Wearing my “PIH EMR” hat, it doesn’t have much of an affect on us since we are running in a CI environment and are regularly cutting gold releases the include snapshots of modules.
Not sure if @mseaton or @cioan would weight in differently on the affect on our Rwanda, Malawi and Lesotho implementations (that aren’t yet on the “PIH EMR”)
@burke and @maurya I like this idea and am more than happy to help in any capacity I can. I also agree with @wyclif that @maurya would make a great Release Manager
I would be glad to be owning the Release Management process.
I agree that there is no set development schedule for all the modules also, I agree there will be implications for following this. That said, as long as there is no deadline, or a freeze time new features or important features will turn up. Until and unless it will break the functionality I believe if changes not included by the set time they should be postponed to the next release. Module owners should create a branch for this release by the scheduled time and accept any new changes for future releases and any functionality breaking feature will only be included in the release branch after the freeze time.
I’m not very restrictive about when a deadline is set until it is set that new features should be completed by the release time to be included in the current release.
True, Implementations should comment on how this will affect their workflow, and I’m happy to hear from @mogoodrich that PIH wont be affected by this.
This again brings up a question that we have to put focus on. Having so many releases, there should be a focus on having a software update manager. Though it might be a long time before we have a sophisticated one that can handle all the data consistency issues and previous platform compatibility. Having such a timeline will help us include such a software updater included in our schedule in near future for future releases if not backward compatible.
I don’t think this is feasible, at least not as I’m reading it.
The reference application modules are shared code with other distributions (e.g. PIH-EMR, Bahmni), and for many of these modules the primary owner and/or main contributors are doing that as paid employees of the organization (e.g. PIH, ThoughtWorks) who contribute to OpenMRS via building those distributions. It would be a significant change to start telling these module owners (and their sponsoring organizations) to
(a) introduce and enforce code freezes (that will slow down their work)
(b) start doing release branches (that will slow down their work)
So, my suggestion is that we first try to make things work without introducing additional hoops that contributors will have to jump through.
E.g. we try something like:
there is a 2-3 week window (known well in advance) where each module must be released
it’s up to the module owners to make this happen
once a module has been released, module owners may continue to allow more changes…
…however until the OpenMRS release comes out, module owners need to be prepared to do another bugfix release on a couple days notice.
Again a valid point of not enforcing the contributors the additional burden of managing the release branch maintenance.
But, if the release manager/me(initially as I agreed to own the process) is added as an owner to the module, I would be glad to manage the release branch.
This would not put any additional load on the module owner.
As this process would have a time span of 2 months it wont be a burden for me or a release manager to handle this.
I don’t think I have conveyed myself clearly and gave a wrong impression, these code freezes are figurative meaning they would not stop anyone’s work and we will continue to accept new code changes only they will not be included for the current release so consider them as checkpoints – we will not stop the game but save it until that point. These will not add to the load of anyone’s work as we are releasing twice a year anyway. They don’t have to be sudden, the module owners will be informed about this 3 months in advance. In future, this would not even require a notice.
I am not against module owners having their own priority. But, we as a community agreed on releasing OpenMRS Reference Application in March and September and this should not be delayed because of any single module and should be in control of the collective community rather than the single implementation. Meaning, if new bug fixes have been introduced to the code(these are accepted by verifying the functionality) they should be released for the new OpenMRS version irrespective of the module owners availability.
Reading this over in greater detail, perhaps I shouldn’t have said “won’t have much affect on us.” I’ll blame it on wanting to get a quick response out on a Friday.
We commit at will against the master branches of modules like emr-api and coreapps, and always run and deploy off the latest snapshot of the master. So, in that sense, we don’t really care that much about when a module is released or what the released version is (for PIH-maintained modules, we have a mvn trigger in our build script to upgrade the versions of dependent modules to the latest snapshot).
But, having anything more than a very short/limited code freeze would be a blocker for us.
If the release manager wants to cut a release branch of all modules and be responsible for maintaining that branch (allowing development along master to continue) that’s fine, but I think maintaining those branches and accepting/merging bugfixes might be much more work than expected.
Two things have struck me as I watch this release (from somewhat of a distance)
It seems like it has been a real pain to handle/coordinate updating all the module version numbers (@wyclif could probably weigh in), and making sure that the dependencies line up
It’s caused me very little pain, but also I care very little about it (because the PIH EMR build is running in CI environment, and not depending on any particular released versions of modules).
Although I’m (very) happy it has’t been painful, the fact that it has had so little effect on the PIH EMR implementation (either positive or negative) strikes me as a disconnect of some kind, and suggests that we (OpenMRS) may be approaching releases in the (completely?) wrong way?
However, I don’t have any clear, obvious suggestions of what to do (besides trying to set aside some time and brainspace for thinking about the issue at OMRS15). Would it be possible to handle OpenMRS releases in a CI/CD kind of way? Has the OpenMRS distro become such a complex bundle of modules that a formal mvn release process is just not feasible?
Would also be interested in learning more about how Bahmni does their releases.
@mogoodrich actually the distro modules and the ref app standalone are released with a single click in bamboo, so i don’t think the act of of releasing is complex but the release manager is required to follow up on a bulk of tasks and we have tried to document them. Also things liking coming up with a list of contributors is much work, for 2.2 i tried to automate it and i hope to convert the code into a maven plugin to be used for future releases.
)
I agree with 
