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 TODO: read this during next release, and update below.

TODO: There was a thread on octave-maintainers maillist about automating most of this with a Makefile. The latest version of this Makefile is typically in the "interval" package. We might consider adopting it for doctest too.

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).

• Double-check version number in Makefile.

• Test regenerating the html documentation.

  • pkg install -forge generate_html
  • pkg load generate_html
  • options = get_html_options ("octave-forge");
  • generate_package_html ("doctest", "html", options)

• Make a package: use fresh clone or copy the directory to "doctest-0.3.0". From inside "doctest" delete .git, .gitignore, .travis.yml, Makefile (anything that doesn't belong in release). Then "tar -zcvf doctest-0.3.0.tar.gz doctest-0.3.0".

• If packages seem ok, then tag the repo with:

  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.

• Then redo the packages.

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

  • regenerating the html documentation.

  • 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.

• Update version numbers in Makefile.

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