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

Difference between revisions of "Branches"

From ZNC
Jump to: navigation, search
(Created page with "This article describes the guidelines for branches in the ZNC repository. == Stable == A stable versioned branch (eg. 1.6.x) contains the latest stable ZNC release, and pote...")
 
(restored from archive.org)
 
(5 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
This article describes the guidelines for branches in the ZNC repository.
 
This article describes the guidelines for branches in the ZNC repository.
 +
 +
<pre>
 +
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__/
 +
</pre>
 +
 +
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 ==
 
== Stable ==
Line 8: Line 20:
  
 
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.
 
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.
 
== Chart ==
 
 
In the following chart, 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.
 
 
<pre>
 
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__/__ ...
 
</pre>
 
  
 
== Guidelines ==
 
== Guidelines ==
Line 37: Line 35:
 
* Configuration changes
 
* Configuration changes
 
* Source incompatible changes
 
* Source incompatible changes
** modules written for 1.x.0 '''must''' build with any later 1.x.y release
+
** Modules written for 1.x.0 '''must''' build with any later 1.x.y release
 
* [https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ Binary incompatible] changes
 
* [https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ Binary incompatible] changes
** modules built for 1.x.0 '''must''' run with any later 1.x.y release
+
** Modules built for 1.x.0 '''must''' run with any later 1.x.y release
 
* Code cleanup and improvements
 
* Code cleanup and improvements
 
* Obstrusive bug fixes
 
* Obstrusive bug fixes
 
* Any other unurgent changes
 
* Any other unurgent changes
 +
 +
 +
{{ambox | type = delete | text = '''Note:''' It is backwards binary incompatible to add, remove, or change even private member variables in headers that modules can include.}}
 +
 +
__NOTOC__
 +
[[Category:FAQ]]

Latest 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[edit]

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[edit]

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[edit]

stable[edit]

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

master[edit]

  • 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