Rhaptos Code Development/Release Cycle

Communication happens on rhaptos@…

Code development with Rhaptos presumes you have followed other instructions for installing a working Rhaptos instance.

Policy 1: only very small, obvious bug fixes go directly to trunk.

As an external developer, provide these as a patch against trunk. If it touches more than one Product, make a devset (instructions elsewhere) This involves branching all the Products, and making a copy of the buildout dirs (FIXME: scripts dir external)

After code is working to the developer's satisfaction, sync your branch with trunk, and retest. Ideally, we run automated regression tests at this point.

Document what the code is supposed to do, and how to install it in top level README.txt and/or INSTALL.txt files in the devset. Consider what happens for installs with existing data (provide an upgrade path) Use the 'partial' datasets to test these. If there is a class of data that needed to test your upgrade that is not present in 'partial', suggests an addition to the test data. Make appropriate additions to CHANGES.txt, at the top, with no version line above (release will handle that)

Submit your shiny new feature to Rhaptos Core.

Policy 2: all submitted code _must_ be sync'ed w/ current trunk

Rhaptos Core is then responsible to smoke test the dev code, and if code is (provisionally) accepted, merge to trunk.

Re-run smoke/regression tests against trunk (buildbot will get these, as well)

Release Time:

* Determine the code set to be released

  • List all Products

This code might help (run from the src/ folder of a devset, replacing branchname):

while read u p ; do t=${u/branches\/branchname/trunk/}; if [ $(svn diff $t $u | wc -l ) != 0 ] ; then echo $p; fi ; done <EXTERNALS.txt 
  • Any non-product code? (xml/xslt transforms. System package upgrade)
  • For each Product, make sure:
    • version number get's bumped
    • CHANGES is updated
    • setup.cfg has tag_build = dev and tag_svn_revision = true

* Create the dev eggs (see notes at dist.rhaptos.org):

  • in each Products.Foo dir, run:

python2.4 setup.py mregister sdist bdist_egg mupload -r dist-rhaptos

  • verify the correct eggs were in fact created

* Create an egg-based dist release (dist.cfg)

  • regression test

* Final release:

In each Products.Foo dir, run:

python2.4 setup.py release

This presumes a properly configured .pypirc, with the line:

release-command = mregister sdist build_mo bdist_egg mupload

* On each frontend:

  • become the appropriate user (in our case www-data: sudo su - www-data)
  • svn up in buildout dir
  • rerun buildout, w/ FE appropriate cfg (we symlink buildout.cfg to the right one, on each machine)
    • note that usually, buildout install instance{,1,2,...} is sufficent
  • restart FEs