Standardization of the Release process is needed as the current process has not been effective enough and has been causing a lot of friction and pressure on the people involved
Please reply to this topic with your opinion on if you support or do not support the list items below. If you have any better Ideas please do mention them as well.
1.Decide on the Release timeline - Starting with a timeline for the Reference Application - @dkayiwa and @wyclif Agreed
Before agreeing to this idea please consider the process, pro’s and con’s for this model of release
Early January: Select release manager for September release. March release manager announces modules. Mid January: Code freeze for March release. Code freeze refers to branching into a release branch which will not accept any new pull requests.(unless some bug discovered in UAT or some code breaking bug is discovered). The normal pull request still get accepted in the master branch of the code **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.
Pros: a. Gives ample time for module owners to release the modules. b. Gives ample time to perform User Acceptance Testing c. Gives ample time to address any issues from UAT. d. Gives ample time for the Release Manager (Generally a new Volunteer) to understand the release process and setup the required e. Have standard release dates for our releases. f. Need not worry about someone committing/accepting a pull request that will delay the release. Will have a release ready stage for the modules.
Cons: a. Have to change our CI release process to release off of the release branch (Not sure how difficult this is @cintiadr might have more knowledge ) b. Will create an extra step of creating/managing a branch, though it might be of minimal load this can either be taken up by module owners or the release manager. c. If any bug is discovered in the UAT, the fix has to be implemented in both the release and the master branch.
2. Make Release Process information more transparent: Release roadmap Pages for the Platform and the Reference Application created when the release manager is chosen (that will transform into Release pages)
The actual tickets in each module that are being included in the Reference Application or the Platform are not visible for the general public to view in the technical roadmap. Presently - An implementer needs to go to JIRA and search in each Module which ticket is being included. A simple inclusion of Jira Tickets as shown in Getting Started as a Developer Page would be fine.
This will allow implementers to understand the Overview/status of features and issues being solved/included in the release. And Interested implementers will be able to push the tickets they want to get included in the release.
3. Include Implementers more in the Release Roadmap: Decide the process of getting features/issues into the release roadmap, this will allow implementers and developers to understand the process and have a say in the release
@wyclif - Presently they are decided on a design call / Developer Call. Darius or Burke say this should be in a specific version, if not done in one version they are bumped to the next version. @dkayiwa - Majority of tickets are decided by the release manager and for grey tickets they are talked about in a Design Call @wyclif - Voting has been used for dev swimlane, and we ignored it recently.
There is a voting system available in the JIRA. Select tickets with highest number of votes and showcase them in the release roadmap page.This will make the process more transparent.
4.Decide on a way to communicate with the interested stakeholders:
After people voting on a JIRA ticket or mentioning that they are interested to get a feature included in OpenMRS people have not got a proper response about the status of the Features/Issues.
To handle this if we have a release roadmap that should solve the problem of knowing the status. But if their issues are not being included the release manager should send out a mail/ Announce in a talk post about why their ticket is not being included or in which release version it would be included.
5. Decide on a way to best showcase download statistics present in sourceforge, they can act as a great metrics -
Sourceforge Download statistics - has great data like the number of times each version has been downloaded and their total( 250,000+ total downloads) and how many countries downloaded it (200+ countries and territories) Though this is not something that would interest the implementers it would definitely allow people new to OpenMRS understand its impact.
This is not something to replace the Atlas module information as that is definitely more accurate and a better metric of the impact of OpenMRS implementations. But, OpenMRS is not just used for Implementation, it is used in many different ways, though we do not have a way to know that now we at least know the quantitative impact.
Presently I’m including them as a link in the wiki under releases like here. I’m not sure if that is the best way to showcase it though.
6.Platform Release Process Improvements
@wyclif - Most of the process included in this release process page can be automated through bamboo and the documentation would shrink but we need approval from the community.
7.OpenMRS 2.0 should not be used for Platform 2.0 as it creates an issue with Reference application 2.0:
@wyclif pointed out that OpenMRS 2.0 has already been used for OpenMRS Reference Application 2.0 in JIRA , Having the same name for Platform will be confusing. Maybe having Platform 2.0 would make more sense.
8. Two Different Release Process Pages Under the Main Release Process Page:
The present release process page is completely about platform release process and the Reference Application Release process is a link under it, it would be nice to have a generic main page and links to the two different release processes.