Current development process:
New work is committed to HEAD. When a scheduled release is code-complete, we do a code freeze, meaning no new features, only bug fixes. This keeps the code stable so that we can reduce the total number of bugs. This also blocks new work, so we branch the code to, e.g., oacs-5-0, and new work continues on HEAD. We spend 1-2 months (or 3-4) stabilizing the branch until it meets the criteria, and we release it. Then we merge oacs-5-0 back to HEAD and start over again.
There are two big problems with this:
- It encourages HEAD to get broken, so we have to stabilize over and over again
- It delays the release of new work
Here is a proposal to address these problems:
1) dot-releases starting with 5.1.1 are calendar-driven. We do a dot-release every month. When we integrate tclwebtest into acs-automated-testing in 5.1, we can also build better smoke tests that make it easier to keep HEAD in known state. With Jeff Davis's batch scripts that implement my instructions for releases, the direct overhead for packaging a release is just minutes.
Benefits:
New code is available in a release form quickly
OpenACS release schedules become more predictable
By not branching, we have to keep HEAD in a very good state, which is good discipline.
New Problems:
It will be harded to make complex changes in HEAD - probably we will have to require people to do the work in branches and not commit until the branch passes the smoke test. Even then, we will have to coordinate complex work more closely with manual testing commitments.
2) Minor and Major releases (5.2, 5.3, 6.0) are feature-driven. We do risky stuff on branches, then merge it after it passes regression, and then do more manual testing and integration testing. This includes stuff with non-trivial database upgrades, and releases that require platform changes.
3) Work on all non-core packages (services, applications, contrib) is always on HEAD and is not directly included in core releases. The recommended way to get new applications is through the APM, which uses the repository on openacs.org.
4) The translation server is deliberately lagged behind releases. We release 5.0, then upgrade the translation server, then ask the translaters to catch up, and then put the full 5.0.0 translations in 5.0.1. This is obviously not ideal, but I think it's a realistic compromise between our resources and the perfect solution.
I think we should do 3 and 4 immediately, and do 1 and 2 starting with 5.1.1. Meanwhile, 5.0.x should come from the oacs-5-0 branch; 5.1 should come from head and have a standard freeze process.
