Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 175 Next »

Release Management

XXX

XXX

XXX

Supported Releases

Version

Current Release

Release Date

Release Notes

Sakai 2.6

2.6.1

15 Oct 2009

Notes

Sakai 2.5

2.5.5

23 July 2009

Notes

Version

Current Release

Release Date

Kernel 1.1

1.1.0-beta03

17 Oct 2009

Kernel 1.0

1.0.12

12 Oct 2009

Release Management

Links to documentation describing important aspects of Sakai's Release Management 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 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.

Supported Releases

Support for releases is subject to the availability of community and volunteer resources to effect that support. Generally this will include the current release and prior releases for which there is a sufficiently large community of folks still running a particular release in production.

You are strongly encouraged to use or closely follow the Maintenance Branch for a release when running in production, as the Maintenance Branches provide access to important bug fixes. The project teams producing the 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.)

(For past releases we welcome volunteers from the community who are still using those releases to participate in a branch management team that will carry-on active management for that version, applying bug fixes, etc. If you're interested, please contact Peter A. Knoop.)

  • No labels