On 2/26/06, David M Johnson <[EMAIL PROTECTED]> wrote: > 1) Release planning > - If you want to add a feature to a release, you assign it to > yourself and set the "fix-for" field for the release you want. (see > the roadmap view in JIRA). > > 2) Development > - If you are working on a feature you mark it as "ongoing" in JIRA > > 3) Monthly RC1: second to last thursday of each month > - If anybody thinks this month's changes warrant a release, they > ensure that user docs, install docs, change lists and database > scripts are updated and they create RC1.
3) Monthly Milestone ... and they tag the repository for X_Y_# and create the X.Y.# build. 3b) They also create a X_Y_#+1 release target in JIRA, and update the nightly build to reference X_Y_(#+1)-SNAPSHOT Meanwhile, mainline development continues in the trunk, and we mark issues "resolved" in X_Y_(#+1) as soon as the fix is committed, citing the SVN revision number for good measure. > 4) Test week > - Testing focuses on those features marked "ongoing" those that pass > testing are marked as "resolved" Testing focuses on those features marked as resolved in X_Y_#. If testing fails, the issue is reopened with an appropriate comment. > 5) Monthly RC2: last thursday of each month > - If somebody rolled an RC last week and testing/fixing went well, > then they create a branch for the release, create RC2 from it and > call for a release vote. We iterate on RCs until voters are satisfied > - While that is happening, mainline development continues in the trunk > - Once release is made, the "resolved" issues are marked as "closed" > in JIRA If somebody rolled a Milestone last week, and testing/fixing went well, then they call for a quality vote on the milestone. If the vote comes back "GA", we update the website to announce a new "best available" release. If mainline development is ready to commence on to the next minor or major release, we tag and branch the current repository for "X_Y_BRANCH" and designate the HEAD X_Z or Y_A. -Ted.
