Process for Upgrading Dev

The following describes the process we'll use for upgrading http://developer.mindtouch.com during a release cycle.

Assumptions:

• with short iterations, trunk should always be in a fairly stable state (no data loss, bugs causing crashes, etc)
• all releases will be done on Thursday evening.  This gives us one day to test before the weekend.
• before upgrading, new api bins will need to be built.

Beginning of dev cycle

• The Thursday after a release is shipped, dev.mt.com is switched to the trunk branch

Middle of dev cycle

• each Thursday, new bins will be built and dev.mt.com will be upgraded

Stabalization phase

• After code freeze, we update dev.mt.com and branch to create the stable branch (discuss if we'll use stable branch at all)
• SVN switch to stable branch (after building new bins)
• Release RC1 to public, announce in blog/forums
• Devs fix any critical issues reported during first 7 days of RC1 testing
• SVN update to address critical issues fixed during RC1
• Release RC2 to public, announce in blog/forums
• Devs fix any critical issues reported during first 7 days of RC2 testing
• Release final product
• loop back to beginning of cycle

Questions

• With short iterations, is it necessary to maintain a "stable" tree (ex: /public/dekiwiki/10.0).  It may make more sense to simply branch trunk into a point release (10.0.3).  This has a few pros/cons:
  • PRO: Less branches to maintain, no need to backport changes
  • CON: if we release 10.0.3 and find critical bugs, the next release needs to be named 10.0.4.  This means any 10.0.4 bugs may need to be reassigned to 10.0.5
  •