river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: release baking
Date Mon, 10 Jan 2011 09:30:20 GMT
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 <sim@qcg.nl> 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

View raw message