Development Process

Suggestions for work flow

These guidelines assume an active development team, adjust as appropriate. They are based roughly on the SymPy work flow.

• In general, significant changes should be done through "pull requests".
• As the software becomes more mature, these should be +1'd by another developer before merging.
• Or in absence of a reviewer, state that you intend to merge in e.g., 24 hours.
• Minor fixes can be pushed directly by those with commit access. Use your good judgment. When in doubt, do a pull request.
• Your changes should add tests where appropriate.

Note that it is possible to send pull requests without commit access to the repository.

Testing

Doctest comes with a number of tests which are quite appropriately written in the doctest format. Before committing changes, please make sure that doctest doctest runs happily (otherwise, the travis-ci continuous integration service will likely send you a gentle reminder that you broke the build 😃).

Publishing a new release

We use x.y.z. Bump y for minor changes or z for "micro" changes (bug fixes etc).

OctaveForge process: http://octave.sourceforge.net/developers.html

Many of the items below on the checklist are automated by the maintainer Makefile in the root directory: see "make help".

Checklist

• Update doctest.m:

  • update version number (remove "-dev", check if bump needed).

• Update DESCRIPTION file (version number and date).

• Update NEWS file (date, version number, reformat).

• Commit (locally for now, no need to push yet). Now you can test locally (using make commands below).

• If packages seem ok, then tag the repo:

  • git tag -a v2.0.0 -m "Version 2.0.0"

  • git push --tags origin master. If messed up and want to change anything after this, need to bump version number (tag is public).

  • Push and push tags to sourceforge.

• Use the maintainer Makefile

  • make clean
  • make octave_pkg
  • make octave_html
  • make matlab_pkg

• The packages will be in tmp/

  • compute the md5sums, upload the packages to github release page, and copy-paste the md5sums.

  • create ticket for binaries and doc tarball on sourceforge.

AFTER release

• Bump version to the next anticipated version and append "-dev" in in doctest.m. See PEP 440.

• Leave old version in DESCRIPTION ("-dev" not supported here). We will bump it at the next release. FIXME: this is unfortunate.