Rationale
Sakai has historically followed a strategy of 'code freeze' in anticipation of a release, whereby the entire trunk is branched at a particular snapshot in time, and from that point forward only verified bugfixes are merged into the branch. This has been an effective tactic in allowing development work to continue while still closely guarding the stability of the code being tested for release. It has also had the benefit of simplicity: a single deadline for everyone to get their work done in time.
It has however often also been too blunt an instrument, one that focuses on a deadline for committed code rather than an overall quality result. Particular components of Sakai are often stewarded by particular teams, evolving on their own timeframes. For some the code freeze comes too early, and the work is hurried, causing problems in QA down the road. Others are ready well in advance of code freeze, but testing on their work is delayed until code freeze is arrived at. An approach which could more supply harness this variability could be more productive overall.
What's more, documentation of the work has not been all that one would hope for. Training staff are not always alerted to the user-facing changes they will need to cope with, decision-makers do not always have a clear idea of what the improvements are and how well they match local needs, and QA volunteers do not always have a clear idea of what it is they need to be testing or what its regression implications might be.
Independent releases of individual components could address these concerns. Rather than take a global snapshot of trunk, tested and documented component versions could be bundled together for general QA.
Expectations on Releases
Individual component teams - whether one person or many - would take on the responsibility of release management for their component. This includes:
- Documentation of the changes, both technical and user-facing as called for. For a more thorough breakdown of the kinds of questions that need answers, see New Feature Documentation.
- Testing that the component is completely functional and internally consistent to the point of release-readiness (i.e. whether it introduces regressions in other components will be a matter for the full Sakai release QA to follow later, though API changes should again be thoroughly documented)
- Recruiting community resource to see all this accomplished, where needed. Foundation Staff will be able to help communicate this need.
If a particular component release version does not meet this standard, it should be expected that a prior stable version of the component will be reverted to for a full Sakai release.