To create new wiki account, please join us on #znc at Libera.Chat and ask admins to create a wiki account for you. You can say thanks to spambots for this inconvenience.


From ZNC
Jump to navigation Jump to search

This article describes the guidelines for branches in the ZNC repository.

master _____________________________________________________________________ ...
         \                       ^  \                 ^             ^
          \                     /    \               /             /
1.7.x      \                   /      v__znc-1.7.0__/__znc-1.7.1__/__ ...
            \                 /             ^             ^
             \               /             /             /
1.6.x         v__znc-1.6.0__/__znc-1.6.1__/__znc-1.6.2__/

In the chart above, branch names are on the left, and tag names along the lines illustrating each branch. Downwards pointing arrows indicate a stable versioned branch being branched off of master. Upwards pointing arrows indicate merges that bring bug fixes from stable versioned branches to the master branch.


A stable versioned branch (eg. 1.6.x) contains the latest stable ZNC release, and potentially additional bug fixes that might not yet have been released. Only fully backwards compatible, stabilizing bug fixes are pushed to the (lowest applicable/maintained) stable branch. A stable branch forms the next patch/bug-fix release. Stable branches get periodically merged to master.


The master branch contains the most up-to-date development version of ZNC. From time to time, instability may occur due to the development of new features. New API and features, changes to the configuration, backwards incompatible changes, and obtrusive bug fixes are always pushed to master. The master branch forms the next major or minor version.



  • Fixes to the internal implementation (.cpp) of ZNC
  • Fixes to modules
  • Fixes to webskins
  • Documentation fixes


  • New API
  • New features
  • Behavioral changes
  • Configuration changes
  • Source incompatible changes
    • Modules written for 1.x.0 must build with any later 1.x.y release
  • Binary incompatible changes
    • Modules built for 1.x.0 must run with any later 1.x.y release
  • Code cleanup and improvements
  • Obstrusive bug fixes
  • Any other unurgent changes