Release Practices

Sakai's release practices have evolved to meet our community's goals for 2008 and beyond:

• Create the highest quality core software.

• Seek to engage new members of the community.

We plan to meet these by satisfying two key release requirements:

• high-quality, easy to deploy and maintain software with long-term support, and

• frequent, easy access to new functionality

The evolution of our release practices was the subject of much on-line discussion leading up to the Newport Beach 9th Sakai Conference, further discussion in conference sessions and BOFs, and post-conference proposals and community feedback. The discussion was also influenced by the community's recent experience with the Sakai 2.5 release process, as well as areas of past consensuses, including maintenance branches, feature branches, experimental branches, and release or freeze timelines. Two additional topics that were considered (minor releases and kernel releases) are not yet incorporated in the guidelines, as community consensus is still being built in these areas.

The most recent evolution of these guidelines, including thoughts on minor releases, can be viewed here. The Original Sakai Release Practices document, is now deprecated, but also provides useful reference materials for those interested in this topic.

Release Practice Guidelines

The following guidelines outline community expectations and practices for the various Sakai release and branch types. They represent the culmination of extensive community discussion and deliberation, as noted above. It is likely, however, that future needs will require the evolution of these guidelines, so we will periodically review them in conjunction with each major release, or more often, if circumstances dictate. (Also, see "Jira – Sakai's Issue Management and Tracking System" for best practices for using Jira in Sakai development.)

• |#Major Releases

• |#Maintenance Branches

• |#Maintenance Releases

• |#Jira Branches

• |#Feature Branches

• |#Trunk

Major Releases

Major Releases are targeted at organizations for which a stable, long-term deployment is desired, and for which access to Maintenance Releases as a resource for bug fixes is critical.

• Predominately driven by the completion of significant improvements and enhancements in Sakai, developed in |#Jira Branches, since the previous major release.

• Also incorporates bug fixes and minor enhancements developed in trunk, and functionality developed in |#Feature Branches since the last major release.

• If such functionality fails to meet a release deadline, then an evaluation will be made to balance the benefits of adjusting the deadline versus delaying the timely availability of other new functionality in the release.

• Major releases are expected to occur approximately every twelve months, early in the calendar year, and be supported by an active Maintenance Branch with periodic |#Maintenance Releases for two years (or longer, if there are sufficient community resources and interest).

• A Feature Freeze approximately six months before the official release, and roughly two months before Code Freeze and QA begins, will help solidify expectations of what will be in a release. (See the Sakai Roadmap for a current overview of tentatively planned Sakai functionality.)

• QA across the whole application carried out through the coordinated activities of the QA Working Group and early adopters during approximately four to six months of QA, beta, and release candidate tags.

Release Timeline

The Release Timeline (or Freeze Timeline) provides a series of freeze dates to help coordinate activities across the projects and to encourage communication to the community about what is intended to be in a release. The release team reserves the right to adjust deadlines, in order to produce a quality release. (See Sakai 2.6 Release Schedule for an example of this timeline in practice.)