Maintenance Branch Merge Policy

Owned by Former user (Deleted)
Last updated: Jun 19, 2015 by Former user (Deleted)
2 min read

Maintenance Branch Merge Policy

Definitions:

  • Bug: JIRA tickets classified as BUG
  • Enhancement: JIRA tickets classified as anything other than BUG

Process:
Small enhancements may be candidates to merge into a maintenance branch only with oversight from the Sakai PMC (sakai-pmc@collab.sakaiproject.org). This means that the merge candidate was discussed and no objections were raised (though no formal vote is required):

  1. How qualifications have been met should be documented in the JIRA
  2. First announcement (see last bullet below) should be sent to the <production@collab.sakaiproject.org>, <sakai-dev@collab.sakaiproject.org> and <sakai-pmc@collab.sakaiproject.org> email lists. Suggested time frame for response is one week.    The date of the announcement should be noted in the JIRA ticket. 
  3. Second announcement (see last bullet below) should be sent to the <production@collab.sakaiproject.org>, <sakai-dev@collab.sakaiproject.org> and <sakai-pmc@collab.sakaiproject.org> email lists. The date of the announcement should be noted in the JIRA ticket.

Qualifications:

Candidates for merging into an active maintenance branch include:

  • Small enhancements may be applied to active maintenance release branches if they meet the following criteria:
    1. The change is narrow in scope (modest changes to a single project)
    2. The change has been reviewed and approved by tool lead for the maintenance branch
    3. The change does not require database changes
    4. The change has been running in production for one month minimum
    5. Changes that could impact internationalization negatively must be tested in two languages that are not variants of the same country.
    6. The change is non-disruptive to the user experience ( I.e. changes that don't require user retraining and are unlikely to break existing customizations). Exceptions to this rule may be made if the change is configurable and is disabled by default.
    7. Prior to merging, the change must be tested with the target maintenance branch, by the requesting institution, using a documented test plan.
    8. The change must be preceded by a public announcement on the production and dev lists that alerts community members to the impending addition of a new feature in one or more maintenance branches. The announcement will describe the new feature, configuration options, test plans, relevant tickets, etc. When the change is committed a follow-up announcement listing the branch revision incorporating the change will be published. The information provided in such announcements will also be added to relevant release notes in JIRA, Confluence and elsewhere.

Quality Assurance and Release Process:

  1. All fixes are verified in trunk before merging into the branch.
  2. When all the fixes are merged, we cut a Release Candidate.
  3. As soon as we get to Release Candidate stage, we only merge blocker level priority fixes.
  4. Blocker bugs, at a minimum, should be re-verified after merging into the branch, either in the nightly server, or the next release candidate QA server.