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.