Start:
    Freeze cocos directory, except for obvious, simple, robust fixes.
    Freeze existing code in samples and test directories
    Additions after the freeze should should be listed somewhere so they
    get tested before release.

Early:
 - Be sure all examples in test dir runs
 - If possible, unit test in utest should all pass.

Finishing:

- Proper updated license header, care to not target files which needs
  other license header

- decide version and date; write it down.
  They should be consistent with previous releases, to not confuse
  users and installers like easy_install or pip
  
  update version and date in
      cocos/__init__.py
      setup.py

  additionally, update version in
      doc/index.txt
      CHANGELOG

- new big capabilities should be updated in
    cocos/__init__.py docstring
    README    
    doc/programming_guide/introduction.txt
    
- Update text files in the top trunk directory
  Keep in mind that
      - README it is also used as reST for the pypi page
        (see 1 in building_release_notes.txt)

      - INSTALL is also used as docs/programming_guide/installation.txt
        (manual copy atm), so use reST- epydoc compatible markup

	- CHANGELOG
	- LICENSE
	- INSTALL
	- README		

- Others updates to setup.py

    - dependencies if needed.

- adjust MANIFEST.in if needed

- build the docs (see 2 in building_release_notes.txt)

- build the package
  ( *.py line endings to unix if building in windows ? careful with
    samples/tetrico/data/block_rotate.py , marked as octet/stream)
  example build command in windows
  setup.py sdist  >build.log

- check log for errors

- verify that non-code resources are included (currently docs\html, cocos\resources)

- install the new package, see 4 in building_release_notes.txt

- Test that the package built with setup.py works

- upload library and docs archives to googlecode , mark as featured; if this is a final release
unmark as featured older packages. Download and binary compare just in case.

- Update cocos2d.org site and the backup( see 5 in building_release_notes.txt)

- upload to pypi ( see 6 in building_release_notes.txt )
  For Release Candidates, alphas, betas we don't upload to pypi (automatic installers can't differentiate between stable or unstable releases, so by example 'easy_install foo' can silently install an unstable release if it where uploaded to pypi) 

  check how the pypi page looks, download the zip / tar and binary compare with the originals.

- tag the release in the repo (see 7 in building_release_notes.txt)

- Update release_checklist_template.txt and or building_release_notes.txt if necessary.

- Announce the release.
	cocos list
	pyar list
	pyglet list
	
- Congratulate yourself and relax :-)
