-
Notifications
You must be signed in to change notification settings - Fork 37
How to make a release
Meng Zhao edited this page Dec 11, 2018
·
3 revisions
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 :)
- switch to correct branch, e.g.
git checkout origin/2.4x -b 2.4x
- simple test run:
nosetests
- check
__version__
inwhoosh/__init__.py
- note: the version number should be already correct (see below)
- check and update the
docs/source/releases/*.rst
- list fixed issues
- list new features
- is the other documentation (e.g. api docs) also up-to-date?
- check for completeness:
- new files?
MANIFEST.in
- new code packages/modules?
setup.py
- Tag the release, e.g.:
git tag -a v1.4 -m "Added tag 2.4.2"
- create a clean temp clone:
git 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
- Switch to clean repo / right branch:
cd whoosh-rel ; git checkout 2.4x
- (build package, install the package into fresh virtualenv, run tests)
- Upload files to pypi:
python setup.py sdist --formats zip,gztar upload
- Go back to normal repo:
cd ../whoosh
- Update
__version__
inwhoosh/__init__.py
so that the current repo code has a higher version number than the current release. git commit -m "Bumping version number."
- switch back to development branch, e.g.
git checkout default
- avoids accidental development commits to maintenance branch
- 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 maint branch, must be fixed before committing the merge to the default branch
- 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)