Bkerensa/drafts/release process

From GlucosioWiki
Revision as of 12:28, 22 August 2016 by Bkerensa (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


This release process helps the Glucosio Core Team and Product Drivers reduce the risk of delivering updates to the end user that introduce bugs or other issues and help reduce user churn.


The following individual roles and responsibilities make up the release management team:

  • Project Leader - Project Leader is involved in overseeing our roadmap and helping prioritize features and releases and has ultimate say in release decisions and product decisions but generally reserves veto power or decision making when consensus cannot be reached.

  • Product Driver - Product Driver leads a product area and is ultimately the product manager who ensures product alignment with the roadmap and vision and helps coordinate contributions to meet product goals. 

  • Code Reviewer - Code Reviewers can be any peer who is able to understand the product code and review it for quality. 

Core Team - Core Team are core contributors who have formal roles appointed by the Project Leader and are actively involved in the day to day management of product or contribution areas.

  • Casual Contributor - Casual Contributors are contributors who are not involved in active management of a product or contribution area and who may do one-off or intermittent contributions.

Landing Commits

All commits to repos should be initiated via a pull request and should should be approved by a reviewer that is not the person proposing the pull request. Pull requests should be made on the development branch of the repo targeted.

When you have created a pull request on development make sure the “Review Needed” tag is added so that other developers on the core team can provide a basic code review to try and identify any issues with the pull request before it is accepted. 

Code reviewers should review the code and if they have questions about how anything is written or believe improvements can be made should comment directly on the pull request so the submitter has the feedback and can make improvements if needed.

Release Cycle

Stable Releases are to occur on the 2nd Friday of every month and Beta Releases can occur anytime in between to allow for testing through Beta Channel.

QA / Validation of Releases

Releases should be tested using the QA checklist for the following lengths of time before they are considered validated for release:


Major Releases - 7 Days
  • Minor Releases - 5 Days
  • Patch Releases - 4 Days

Timing exceptions can be made by consensus of the Core Team, approval of the Project Leader, or approval of Product Driver.

Code Freeze and Release Day

Code Freeze occurs the Monday before the Release Day and Release Days are always on Fridays.

Release Rollout

If available, releases should be rolled out on the following schedule starting on the release day:


Release Day - 20% Rollout
  • 2nd Day - 50% Rollout
  • 3rd Day - 100% Rollout

Exceptions can be approved by Project Leader or are automatically granted for patches that resolve a crash or are a high impact bug.