Release Candidate Process

Core Release Process

Active Development

• Multiple agile teams develop OpenLMIS, in addition to receiving Pull Request contributions
• Microservices architecture provides separation between the numerous components
• Automated test coverage prevents regressions and gives the team the safety net to release often
• Continuous Integration and Deployment (CI/CD) ensures developers get immediate feedback and QA activities can catch issues quickly
• Code is peer reviewed during Jira ticket workflow and in Pull Requests
• Documentation and CHANGELOGs are kept up-to-date along with the corresponding code and demo data

Do Release Preparation

• Verify the pre-requisites, including all automated tests are passing and all CHANGELOGs are up-to-date; see Release Prerequisites 
• Conduct a manual regression test cycle 1-2 weeks before the release, if possible
• Write draft Release Notes including sections on 'Compatibility', 'Changes to Existing Functionality', and 'New Features'
• Shift agile teams' workloads to bugs and clean-up, rather than committing large new features or breaking changes ("slow down" 1-2 weeks before release)
• Schedule for releases is currently monthly patch releases and quarterly minor releases (as of 3.2.0, this has been the schedule since 3.0.0)

Publish a Release Candidate

• Each component that has any changes since last release is released and semantically versioned (e.g., openlmis-requisition v6.3.4 or openlmis-newthing v1.0.0-beta)
• Reference Distribution Release Candidate is released with these components (e.g., openlmis-ref-distro v3.7.0-rc1)
• Share Release Candidate with the OpenLMIS community along with the draft Release Notes and invite testing and feedback

Review Period

• Active Development is paused and the only development work that happens is release-critical bug fixes or work on branches (note: branches are not yet recommended and not supported by CI/CD)
• Conduct a full manual regression test cycle (including having developers conduct testing)
• Run automated performance testing and review results
• Collect all bug reports in Jira, including those from community early adopters, and including bugs in code, documentation and translations, tagging with the RC AffectsVersion and triaging which are critical for release
• Overall timeline for review period should last at least 1 week, during which time subsequent Release Candidates may be published

Fix Critical Issues

Are there critical release issues? If not, after the first Release Candidate (RC1) we may move directly to a release. Otherwise, we will fix critical issues and publish a new Release Candidate (e.g. RC2).

• Developers fix critical issues in code, documentation, and translations. Only commits for critical issues will be accepted. Other commits will be rejected.
• Every commit is peer reviewed and manually QA'd
• Every commit is reviewed to determine whether portions or all of the full regression test cycle must be repeated

Once critical issues are fixed, publish a new Release Candidate and conduct another Review Period.

Publish the Release

When a Release Candidate has gone through a Review Period without any critical issues found, then this candidate becomes the released version of OpenLMIS.

• Release Notes are updated to state that this is the official release and include the date of the release
• Reference Distribution is released! It contains the same components as the accepted Release Candidate and has its official version (e.g. openlmis-ref-distro v.3.7.0)
• Share Release with the OpenLMIS community along with the final Release Notes

Implementation Release Process

Below is the recommended process that OpenLMIS implementations use to receive, review and adopt updates of OpenLMIS v3.