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

Release Practices

  • Sakai Release Practices – main document, needs updating.
  • Some special areas of interest with proposed improvements:
    • Release Timeline – For 2.5 the plan is to move from a single code freeze to a series of freezes designed to improve control over and promote a better understanding of what is ready to go into a release.
    • Maintenance Branch Guidelines – Guidelines for what is appropriate to merge into a maintenance branch.
    • Feature Branches – Guidelines for feature releases; branches of tools containing new functionality that are backwards compatible with the most-recent major release.
    • 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 provides 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.

Maintenance Branches

Support for maintenance Branches is subject to the availability of community and volunteer resources to effect that support.

If you have a fix that you would like incorporated in a particular maintenance Branch, you need to contact the appropriate Project Lead or Branch Manager with your request. Comments in Jira asking for a fix to be merged will probably not be seen by the individuals who can do the merging. Also, do not add the maintenance branch as a fix version as a way of requesting a fix be incorporated; the fix version is used to reflect what versions the fix is actually in, and it will be set appropriately after a fix is merged into a maintencance branch.

  • No labels