This project is no longer actively maintained. Please find Octave Packages at https://packages.octave.org.

Developers

If you want to contribute to an existing package, please contact the package maintainer directly. Contact information is given in the   list of packages.

If you want to contribute a new package, ask in  Octave Discourse for help.

The remainder of this page is mostly outdated and only left for reference.

Code

The source code for each Octave Forge package is on its own individual mercurial or git repository. To clone all package repositories locally, we provide a meta-repository  octave-forge.

The code of this website can be found in the repository  project-web.

Contributing to Octave Forge

GNU Octave (a.k.a. Octave core) provides the core language, while Octave Forge provides packages for it. For example, the image, control, signal, and statistics packages are part of Octave Forge.

For contributions to Octave core please see its  Octave Developers Page. To contribute to Octave Forge, please read on.

Contributing to Octave Forge in general

If you'd like to make a general contribution, please contact the  maintainers mailing list.

Taking over maintenance of existing packages

Currently unmaintained packages are listed at our  packages page. However, this list might not be up-to-date. If you think you could help with maintenance of a particular package, please step forward and contact the last known package maintainer or the  maintainers mailing list.

Contributing to existing packages

Each Octave Forge package (with exception of some old packages) has its own code repository. Most use  Mercurial although a few prefer  Git. To contribute to a community-maintained package (those listed in the first group at the packages page):

  1. Clone the package
  2. Create a patch
  3. Submit it to the bug tracker or to the patch tracker

To contribute to an external package (those listed in the second group at the packages page), contact the package maintainer for the suitable procedure. External packages might use an external repository for primary package development. In this case the repository at Octave Forge only gets updated during package release and you should look elsewhere for the current development branch of the package.

Clone the package

The  package list and the overview page of each package contain links to web interfaces of the respective code repositories. There, a command line example for cloning the repository is given.

Create a patch

After cloning the most recent version of the package, make your desired changes to the code. Many packages provide a maintainer Makefile and you can run the modified package locally with the command make run to test your changes in an interactive Octave session. Once all changes are complete:

  1. Update the working directory
    hg pull && hg update / git pull
  2. Commit changes
    hg commit / git commit
  3. Export the changes to a patch file
    hg export -r tip / git format-patch -1 HEAD

Submit the patch

Submit it to either the  bug tracker if it fixes a bug, or to the  patch tracker if it adds new functionality. Then wait for it to be reviewed. If the package maintainer is known, please add her/his address in the field Mail Notification CC to speed up the review.

Alternatively, you may host a clone of the package repository wherever desired and request a pull on the patch tracker. This is especially useful for larger changes. It is also possible to submit a new modified file, but creating a patch as described above greatly increases the review and acceptance time.

Contributing new packages

If you want to contribute with a new package, mention this on the  maintainers mailing list. You should decide if you want your package to be community-maintained or external.

Community packages

Community packages are attempted to be coordinated between each other and with Octave. To facilitate this, their maintainers are expected to:

  • cooperate, if asked, with Octave Forge in achieving and implementing decisions regarding the package. The maintainers voice will have a large weight, but decisions may sometimes even relate to name changes of functions, the inclusion of new functions into the package, or assigning of functions to a different package or to Octave.
  • keep the Octave Forge clone of the package repository current.
  • handle patches created against the currently developed heads at the Octave Forge repository, or pushed to the Octave Forge repository, by others. In occasional cases, a patch with only formal changes, or with a non-intrusive fix required to be compatible with new Octave versions, may be pushed by others (typically administrators) even without asking before.

External packages

Decisions on the content of external packages are solely in the authority of the package maintainer.

External repositories

Both community and external packages may of course have external clones of repositories where their maintainers accept contributions by others. Maintainers may publish releases outside Octave Forge, possibly under different package names. If releases at Octave Forge and outside of it have the same name and version, they should be identical.

Requirements for packages hosted at Octave Forge

Like Octave itself, the packages provided at Octave Forge are  Free Software (free as in free speech).

Licensing
  • The package code must be either in the public domain or covered by a  Free Software License.
  • Any code linking to GNU Octave (oct-files) must have a license compatible with that of GNU Octave (GPL3+).
  • For community packages, all code is required to be under a license compatible with that of GNU Octave, or to be in the public domain.
  • Any file containing non-trivial code must contain either a notice that it is in the public domain, or (better) a copyright and license notice.
  • The functioning of the package must not depend on programs that are not Free Software.
Releases
  • A release at Octave Forge must be reproducible from a corresponding revision present in the code repository at Octave Forge. The source files in this revision must be identical to the source files in the release.
  • To facilitate reviewing, reproducing the release from the repository must be possible with a Makefile in the top level package directory. If possible, the  template Makefile should be used.
Symbol uniqueness

Except if overwriting existing functions is intended, symbol duplications over function names, class basenames, and namespace (base)names should be avoided. Note that community packages may violate this rule by using symbols which are already defined in external packages; this can be necessary e.g. for Matlab compatibility.

The general structure of a package is described in the  Octave manual. Additionally, in Octave Forge packages:

Octave Forge maintains an  example package, which provides possible solutions for some common problems. It is a work in progress. There are no releases for this package.

Making a package release

The details of the release procedure depend to some degree on the structure of the package.

For more information

Project history

Before 2007, Octave Forge did not even have packages since Octave did not had a package manager yet; all of Octave Forge was a single extension to Octave. Development of packages were concerted and releases were synced. Because of this, all development happened in a single repository, it was a single project.

Before February 2010, Octave Forge was originally an Octave distribution. There were no individual packages and everything was a single repository, with everything released at the same time. The original distribution had 3 parts: main, extra, and non-free. An extra directory in the  legacy SVN repository was also available for admin.

As the number of packages increased it became too difficult to coordinate development of the packages, and with the introduction of a package manager in Octave there was no need for that either. This led to the creation of individual packages, released at different times as each package manager saw fit. They were still all under a single giant SVN repository (although with SVN one can easily clone only a subdirectory).

The non-free section was eventually removed, and two prerequisites were defined for inclusion of code in Octave Forge: a GPL compatible license and non-dependency on GPL incompatibility code.

Eventually subversion became a burden as some packages preferred to have their main development happen somewhere else. Between 2013 and 2016, individual packages migrated their history from subversion to a DVCS such as mercurial and git. History of whole package development was migrated to the new repositories.