-
Notifications
You must be signed in to change notification settings - Fork 37
How to make a release
Meng Zhao edited this page Dec 7, 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 :)
= Creating a maintenance release =
** note: the version number should be already correct (see below)
** list fixed issues ** list new features
** new files? {{{ MANIFEST.in }}} ** new code packages/modules? {{{ setup.py }}}
Tag the release, e.g.: {{{ hg tag -r 12345678abcd -m "Added tag 2.4.2 for changeset 12345678abcd" 2.4.2 }}}
** 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
Update {{{ version }}} in {{{ whoosh/init.py }}} so that the current repo code has a higher version number than the current release.
** avoids accidental development commits to maintenance branch
** 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
** 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)