- 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.
- Experimental Branches – Guidelines and workflow for dealing with experimental branches to the main Sakai code.
- Maintenance Branch Guidelines – Guidelines for what is appropriate to merge into a maintenance branch.
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.
Use the Maintenance Branches
If you are planning to run in production, then you are stronlgy encouraged to use the maintenance branch for a release. The Maintenance Branches contain important bug fixes that the community has not had time to incorporate into a release. Generally these fixes have not been subjected to the formal Sakai QA process, however, the project teams responsible for them have preformed limited, issue-specific QA. And, as many organizations pick-up the maintenance branch fixes for local testing and use in production as they become available, a fair amount of QA is acheived in the end.
- Next Release
- Sakai 2.5.0 is tentatively scheduled for release on 01 November 2007, however, there is on-going discussion of slowing the pace of Sakai releases down from every six months to once a year after this.
- Past Major Releases
- Sakai 2.4.0 release site (Sakai 2.4.x Maintenance Branch)
- Sakai 2.3.0 release site (Sakai 2.3.x Maintenance Branch)
- Sakai 2.2.2 release site (Sakai 2.2.x Maintenance Branch)
- Sakai 2.1.2 release site (Sakai 2.1.x Maintenance Branch)
- Sakai 2.0.1 release site
- Sakai 1.5.1 release site
- Sakai 1.0.0 release site
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.