Release Management Overview

Sakai release support is subject to the availability of community and volunteer resources. Generally this will include the current release and prior releases for which there is a sufficiently large institutional user base.

Implementers are encouraged to deploy Sakai release tags or source or binary artifacts. A number of schools use maintenance branch code in production in order to pick up bug fixes as they become available. The project teams providing fixes provide a minimal level of testing, however, a great deal of community QA is achieved for each fix by relying on the local QA processes of organizations preparing the fixes for deployment to production. (See the Release Practice Guidelines for further information on how and what goes into these branches.)

Starting with Sakai 2.6 low-level services have been repackaged as the Sakai "kernel" and are now released independently.

These prior versions of Sakai are no longer supported or recommended for production use.     

Links to documentation describing important aspects of Sakai's release management practices and processes:

• Release Practice Guidelines - Community expectations and practices surrounding the management of the various Sakai release and branch types (i.e., Major Release, Maintenance Branches, Maintenance Releases, Jira Branches, Feature Branches, and Trunk). (See also Jira Guidelines.)
• Security Guidelines - Our policy for reporting, handling, and resolving security related issues in Sakai.
• Release Management Meetings - Generally weekly discussions of how work on releases and maintenance branches is proceeding.
• Tool and Service Scorecards - A "Scorecard Working Group" formed to tackle the issue of how to improve upon the current Core/Provisional/Contrib Tool Status system and its criteria. The goal being a scorecard-like system to provide the release team with guidance on what to include in a release, and organizations deploying Sakai a comparative evaluation of tools' and services' capabilities.