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.
Branches: Difference between revisions
>Jpnurmi Second attempt to clarify the chart |
restored from archive.org |
||
Line 46: | Line 46: | ||
__NOTOC__ | __NOTOC__ | ||
[[Category:FAQ]] |
Revision as of 21:22, 3 April 2017
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.
Stable
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.
Development
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.
Guidelines
stable
- Fixes to the internal implementation (.cpp) of ZNC
- Fixes to modules
- Fixes to webskins
- Documentation fixes
master
- 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
Note: It is backwards binary incompatible to add, remove, or change even private member variables in headers that modules can include. |