> > > > 1) Tag a candidate release in Subversion. This is critical -- without > it, we can't do the testing proposed in the next point. >
But do you want to test a specific SVN revision ? Or actually files that are released as a whole (packages) ? Or both ? See my reply next. > > 2) Test it for nnn days. This time period, for example 30 days, > provides a period of time, when any team member can voluntarily test > the candidate release. He can do this by following your steps (1-3), > in the release section of the ValidationProcess document. > Step 1, 2 and 3 tells how to put include files into a release by registering it in TORELEASE. As you know (do you know ?), filling TORELEASE file is a continuous process, once you've written, tested and discussed about your library, you just put it in TORELEASE and that's it. That's how we're able to provide weekly builds (bee packages). > > During this time period, any bugs can be reported, prioritized, etc. > As this is a continuous process, bugs occuring at this time are usually packaging bugs (missing a specific documentation file, empty directory, etc... these are just examples). Functional, library related bugs can occur (and have occured) but this is usually a sign that something wrong happened before (buildbot didn't catch that things, because... for instance). And, since this is a continuous process, 30 days look rather too long to me. Cheers, Seb -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
