Skip to content

CORAL Release Procedure

Jump to bottom
rtatterson edited this page Mar 11, 2024 · 8 revisions

CORAL Release Day

CORAL is released on a non-Friday weekday. CORAL releases are planned twice a year: February and August.

CORAL Release Checklist

  1. Branches
    • Master: reflect what’s in the production environment, only tagged release
    • Develop: contain completed (and tested) upcoming features
  2. Users/SC create issues on Github
    • Users report issues via Github or in the CORAL Community Discussion and SC member can create issues in Github for community members if necessary
    • Label Issues as bugs or enhancements or for SC review
  3. SC reviews issues and decides on milestone label. The milestone label follows the format [Year].[Month]. For example 2020.09
  4. Developers create pull requests targeting the development branch
    • Link pull requests to issues
    • Add milestone to pull request
    • Tag pull requests as bug or enhancement
  5. Developers (someone different from who created the pull request) comment, test, approve, and merge pull requests into the development branch. Anyone with access to a sandbox can test pull requests, but only developers can merge them.
  6. Documentation task group members create documentation on merged pull requests. Pull requests can be tested by developers on SC in a sandbox environment
  7. Developers/Release Manager draft a release with release notes (new features, bug fixes, new system environment, known issues) and tab version number
  8. Developers test pre-release of the development branch and fix any discovered issues
  9. Documentation task group create documentation branch for documentation version being replaced by the latest documentation release. Tag this documentation version accordingly.
  10. Documentation task group update documentation to reflect what’s in master before merged into master. For beta release, this step can happen after the beta release is published.
  11. Developers merge development branch into master
    • Open a pull request by comparing changes from development to master
    • SC member/ Affiliates member approve and merge the pull request. Note that thorough technical review is usually not required at this point, because the technical review has typically been done when each pull request is merged into the development branch. However, testing of all the consolidated pull requests should be done before signing off on a release during Step 8.
  12. Developers update the status of the issues
    • Issue status need to be closed as they are merged.
  13. Developers/Release Manager publish the release with release notes
  14. Documentation task group update website and announce release to users. Not needed for beta release.
    • Update download page https://coral-erm.org/download/
    • Prepare announcement on social media, news section on website and any community communication platforms

Roles

  • Release manager
    • Coordinate releases
    • Call special meetings for releases
    • Appointed for each release
  • Developer (SC member or anyone from the community)
  • SC (see current membership on CORAL website)
  • Affiliate (see current membership on CORAL website)
  • Documentation task group
    • Work with developers to create release notes and documentation for users.
  • Users
Clone this wiki locally