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 79 Next »

Release Practices

Proposed Release Practices Guidelines

The comment period on the updated Release Practices Guidelines will end 31 January 2008.

  • Some special areas of interest with proposed improvements:
    • Release Timeline – These guidelines will evolve along with the release practice guidelines.
    • Pre-Release Branch – Guideline on how code gets merged into a release (e.g., 2.5.0) once a we've branched from trunk
    • Maintenance Branch Guidelines – Guidelines for what is appropriate to merge into a maintenance branch.
    • Feature Branches – Guidelines for feature branches; new functionality intended for a future release, but available in a form that is compatible with the most-recent major release and not appropriate for a maintenance branch.
    • Experimental Branches – Guidelines and workflow for dealing with experimental branches to the main Sakai code.

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 acheived for each fix by relying on the local QA processes of organizations preparing the fixes for deployment to production. (See the Maintenance Branch 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