-
-
Notifications
You must be signed in to change notification settings - Fork 17
How to make a release
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 help to fix it :)
1 - Switch to correct branch, e.g. git checkout origin/2.4x -b 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 all 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.: git tag -a v1.4 -m "Added tag 2.4.2" 8 - Create a clean temp clone: git clone whoosh whoosh-rel
- Touch 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 ; git checkout 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 - git commit -m "Bumping version number."
15 - Switch back to development branch, e.g. git checkout default
- Avoids accidental development commits to maintenance branch
16 - Merge maintenance branch into default branch: git merge 2.4x
- gets all fixes, doc updates, new tags, etc.
- Problem: also gets the wrong version number from main branch, must be fixed before committing the merge to the default branch
17 - Announcements:
- whoosh mailing list
- (add more?)
- 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)