This seems like a sensible idea. Good one, Sim. And thanks for on the release procedures wiki page!
On Mon, Jan 10, 2011 at 9:20 AM, Sim IJskes - QCG <[email protected]> wrote: > 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 >
