Ted Husted wrote:
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.
my opinion is still that this sounds overly complex for Roller's
situation. i think our current system using release candidates is
working fine and doesn't need to change right now. maybe in the future
as the project continues to grow we will decide this milestone approach
is better, but for now I would say that I haven't seen a sufficient
reason to change our current system.
-- Allen
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.
