Development guide

The programming language of libburnia is ANSI C. Its build system is autotools, but the sources should not depend on that. The target operating systems for now are Linux with kernels >= 2.4 and FreeBSD. Any special dependency to the operating system must be in source files separate from the generally portable C code.

Please try to keep the current coding style in each of the source files you want to change.

The APIs and ABIs of released library versions are strongly protected towards the future. Substantial effort must be made in order to maintain compatibility to the previously released version. A break of compatibility and thus incrementing of SONAME is only the outmost last resort, if ever. This shall ensure that applications can be linked dynamically with all libraries which are younger than the versions which where present at compile time.

Patches

Patches should be attached to (new) tickets in our ticket system. When starting to work on something, please do assign yourself to a particular ticket/task (or create a new one if not present) to avoid duplicate work. We don't use Changelog files - we aggegate the tickets on a per-version basis to get a quick overview of what changed. By contributing code, you accept that your code goes under copyright of respective module copyright owner/s.

Note: this is only for contributors, developers can commit to repository if they are sure everything works.

Tickets

When opening tickets please fill them properly (email, description, type, priority, milestone, version, keywords, and component).

Commit policy

A general rule of a thumb is to make more small commits instead of one huge commit. Please be descriptive in your commit messages.

Releases

All releases need the ok of Mario Danic. Releases of libisofs need the ok of Vreixo Formoso. Releases of libisoburn, libbburn, cdrskin, xorriso need the ok of Thomas Schmitt. Release preparation includes a feature freeze and careful testing.