| Warning |
|---|
Draft for discussion |
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 a 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 then testing on their work is delayed until code freeze is arrived atthe deadline. An approach which could more supply harness this variability could would be more productive overall.
What's more, documentation of the work has not been all that one would hope forreleases has often left something to be desired. 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 needsadvantages the release may bring to them over a prior version, 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 beare.
Independent releases of individual components, coupled to clear expectations about what these component releases should include, could begin to address these concerns. Rather than take a global snapshot of trunk, tested and documented component versions could be bundled together for general QA.
...
If general release QA could begin by bundling together tested and documented component versions, this should provide firmer footing for the release process than a single, global code freeze.
Expectations on Component 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 complete breakdown of the kinds of questions that need answers, see Component Release Documentation.
- Verification through testing that the component is completely functional and internally consistent to the point of release-readiness (i.e. whether it unwittingly introduces regressions in other components will be another matter, though API changes should again be thoroughly documented)
- Recruiting community resource to see all this accomplished, where needed. Foundation Staff should be able to help communicate this need, and will often be able to work with component teams to coordinate effort as the occasion arises, but this should not be assumed in every case.
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.