On 08-01-11 14:51, Peter Firmstone wrote:
I usually review the docs myself, check everything still makes sense,
make sure we're referring to the spec as Jini and the implementation as
River, check for broken links etc, add the latest bug fix notes, ask
others to review, once everyone's happy with the docs, then move onto
the next task.
Shall we declare this as a continues process? Documentation should be
correct as code should be, and if defects in documentation are detected
they should be filed the same as other bugs and handled in the same way?
Whe can then declare a release-candidate at any time of the development
process, when we think we have something new or better to share with the
world.
Shall we define:
At any moment the PMC can initiate a release.
Major/minor is decided.
Branch is made. (output: candidate)
Branch is checked, amended, tagged (output: release), distributed (in
broad terms).
We can then have a release process that from the moment of the branch
can run concurrently from trunk development, and we have a stable
reference point, to base our release candidate evaluation results on.
IMHO this is compatible with
<http://incubator.apache.org/river/development-process.html>
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
