1. Matt Chaput
  2. whoosh

Wiki

Clone wiki

whoosh / HowToRelease

Note:

  • work in progress, trying to document how releasing whoosh works
  • created in the hope to make the release process better and to avoid forgetting something
  • if you find issues / missing stuff: please fix :)

Creating a maintenance release

  1. switch to correct branch, e.g. hg up -C 2.4x
  2. simple test run: nosetests
  3. check __version__ in whoosh/__init__.py
    • note: the version number should be already correct (see below)
  4. check and update the docs/source/releases/*.rst
    • list fixed issues
    • list new features
  5. is the other documentation (e.g. api docs) also up-to-date?
  6. check for completeness:
    • new files? MANIFEST.in
    • new code packages/modules? setup.py
  7. Tag the release, e.g.: hg tag -r 12345678abcd -m "Added tag 2.4.2 for changeset 12345678abcd" 2.4.2
  8. create a clean temp clone: hg clone whoosh whoosh-rel
    • touches all files so their mtime is current, this avoids trouble for people not using --force option with setup.py install
    • only stuff in the repo is in whoosh-rel dir, no other crap
  9. Switch to clean repo / right branch: cd whoosh-rel ; hg up -C 2.4x
  10. (build package, install the package into fresh virtualenv, run tests)
  11. Upload files to pypi: python setup.py sdist --formats zip,gztar upload
  12. Go back to normal repo: cd ../whoosh
  13. Update __version__ in whoosh/__init__.py so that the current repo code has a higher version number than the current release.
  14. hg commit -m "Bumping version number."
  15. switch back to development branch, e.g. hg up -C default
    • avoids accidental development commits to maintenance branch
  16. merge maintenance branch into default branch: hg merge 2.4x
    • gets all fixes, doc updates, new tags, etc.
    • problem: also gets the wrong version number from maint branch, must be fixed before committing the merge to the default branch
  17. Announcements:
    • whoosh mailing list
    • (add more?)

Branches in the repository

  • 2.4x = release maintenance branch for 2.4.x (do simple bug fixes there). Do not merge default into maintenance branch.
  • default = development branch (do development there, but keep it usable). Now and then, merge maintenance branch into default (so default gets the bug fixes also).
  • xxxxx = branch for critical development (when doing big stuff, breaking things, unsafe outcome: create a separate branch, merge into default on good outcome)

Updated