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

• TODO: processes around Octave package releases have changed in 2022: update below.

• Update doctest.m:

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

• Update DESCRIPTION file (version number and date).

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

• Commit (locally if you want, 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 v0.9.0 -m "Version 0.9.0"

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

  • Push and push tags to SourceForge (as well as GitHub).

• Use the maintainer Makefile

  • make clean
  • make release
  • make matlab_pkg

• The packages will be in tmp/

  • note the md5sums from "make release" above.

• SourceForge file-hosting: subject to change, no longer required.

  • TODO: consider replacing and automating most of this with GitHub Actions
  • create ticket for binaries and doc tarball on sourceforge (posting the md5sums and sha256sums).
  • Octave-Forge admins will tag.
  • After this happens, fetch and then push that tag to github.
  • follow the "Admin" instructions from https://wiki.octave.org/Reviewing_Octave_Forge_packages
    • push .tar.gz using web interface
    • Can use sftp to look around then soemthing like: rsync -auvn --delete tmp/doctest-html/doctest/ <user>@web.sourceforge.net:/home/project-web/octave/htdocs/packages/doctest/

• upload both the Octave and Matlab packages to GitHub release page.

• File a merge request to update https://gnu-octave.github.io/packages/doctest

  • I think its ok to self-merge, TBC.
  • example from 0.8.0: https://github.com/gnu-octave/packages/pull/227

AFTER release

• Append "+" to the version in doctest.m, DESCRIPTION and NEWS.