Skip to content

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 =

switch to correct branch, e.g. {{{ hg up -C 2.4x }}}

simple test run: {{{ nosetests }}}

check {{{ version }}} in {{{ whoosh/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.: {{{ hg tag -r 12345678abcd -m "Added tag 2.4.2 for changeset 12345678abcd" 2.4.2 }}}

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

Switch to clean repo / right branch: {{{ cd whoosh-rel ; hg up -C 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 }}} in {{{ whoosh/init.py }}} so that the current repo code has a higher version number than the current release.

{{{ hg commit -m "Bumping version number." }}}

switch back to development branch, e.g. {{{ hg up -C default }}}

** avoids accidental development commits to maintenance branch

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

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)
Clone this wiki locally