- Small enhancements may be applied to active maintenance release branches if they meet the following criteria:
- The change is narrow in scope (modest changes to a single project)
- The change has been reviewed and approved by tool lead for the maintenance branch
- The change does not require database changes
- The change has been running in production for one month minimum
- Changes that could impact internationalization negatively must be tested in two languages that are not variants of the same country.
- 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.
- Prior to merging, the change must be tested with the target maintenance branch, by the requesting institution, using a documented test plan.
- 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:
- All fixes are verified in trunk before merging into the branch.
- When all the fixes are merged, we cut a Release Candidate.
- As soon as we get to Release Candidate stage, we only merge blocker level priority fixes.
- 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.