Net-SNMP Release Policy

Important Note

While this policy formally becomes fully active January 1st, 2006, much of it has already been in operation prior to this time. This document is merely a formal codification of what has been general policy for a while now. Issues with this policy statement should be discussed on the net-snmp-coders mailing list.

Net-SNMP Release Ethos

The Net-SNMP software is being used on a variety of system, by people with a wide range of experience and expertise, both "as supplied" and as the basis of assorted network management extensions. It is also distributed widely by an increasing number of O/S vendors as part of their distributions.

For all of these users, it is vital that software issued by the project is reliable and stable, with as smooth a progression as possible from one release to the next.

To achieve this, a number of basic principles should underly development of the Net-SNMP software:

  1. All releases should be backwards-compatible with previous versions whenever possible - both in terms of application behaviour and library APIs (this is further described below).
  2. Bug fixes should be applied to all relevant and active patch branches - not simply the most recent line. The project actively maintains several branches, and may need to release earlier versions of the code. Critical (E.G. security related) fixes need to be applied to closed branches as well, as it may be necessary to even release code from a closed branch at some point. It is much easier to maintain consistency across the SVN tree by applying necessary patches to each tree at the same time.
  3. All code released should have been properly tested on as wide a range of systems as possible. A stable code base is necessary to achieve this, implying that code changes should be clearly monitored and controlled during the run up to a new release.

This document describes the policy for Net-SNMP development, designed to support these aims. This policy is intended to provide guidelines to support the aims listed above, not a straight-jacket to restrict the development of the project. They are constructed in such a way as to make the rules always boil down to human decisions when the more simple rules seem inappropriate.

The primary final rule in this document always falls to +N voting. Don't waste time arguing whether something meets the criteria of a show-stopper bug, a new feature, a simple bug, etc. - just get the needed +N votes to accept an individual patch instead. This is more efficient, and focuses the argument on the technical issue (you know, the important ones) rather than philosophical debates.


The following terms are used in this document.


Anyone contributing to the project by submitting code - either directly to the SVN repository or via patches sent to the mailing lists or SourceForge tracker databases. If you understand the issues involved (and can discuss them sensibly), then it's reasonable for you to submit an opinion. A developer is considered an active developer if they have been participating in the last 3 months of the project.

Release Manager

The person responsible for producing a particular release. Release managers are appointed by Wes Hardaker and are listed in the schedule document (when it's up to date).


Refers to the net-snmp-coders mailing list where all active discussion about the project occurs.


Differences in opinion are resolved by a generic voting mechanism: +N. +N means that at least N more developers should agree than disagree with a given proposal (i.e., "yes votes" minus "no votes").

For example, a +3 requirement to include a patch during the RC release cycle would mean that active developers indicating support for applying the patch would need at least 3 votes more than those who object (e.g. tallies of 3-0, 4-1, 5-2, ...).

Calling for a vote ("CFV") may force a delay in making a scheduled release, to allow this vote to take place. The Release Manager may need to issue the release before the end of the voting period which is a judgment call left to the discretion of the Release Manager and the other "Resolving Disputes" precedence discussed below.

Thus, when a release manager has indicated that the next release will be published on Friday, all CFV requests should be issued by Thursday to ensure they have 24 hours to collect votes.

Supported System:

An OS for which there is an active developer prepared to ensure that the package works properly on that system. (The Net-SNMP project is driven by volunteers, and we can't force developers to work on a platform they're not interested in.)

Note that as active developers come and go, and as their attention is attracted to and distracted from certain systems types, the Net-SNMP project may gain or lose support for a given system. However, emphasis should always be placed on trying to ensure that changes do not break a system that was once working. Portable code is very important to this project and great care should be taken to make sure that new code doesn't introduce system incompatibilities.

Show stopper:

A show stopper is a condition which indicates the release cycle can not progress forward without the issue being fixed.

Any active developer may request that a release process be halted and may request a CFV on the -coders list. A CFV count of +1 will indicate a show-stopper and the release-manager should act accordingly. A show-stopper will be considered resolved once a second +1 CFV has been reached proposing to continue the release. (The rough up-shot will be that at least 2 people have switched positions on an issue because of discussion or resolution).

Examples that active developers are likely to accept as show-stoppers are:

Bug Fix / New Feature:

In practice we've found it impossible to perfectly draw a line between bug fixes and new features. Most of the time it should be fairly clear, but in practice we've found that much of the time patches can frequently lie in the "gray area". Because of this we do not attempt to provide specific definitions for these. The gray areas for cases like these should be discussed on -coders and is subject to the current +N voting required for the current release cycle phase in progress.

Release Cycle:

The Net-SNMP project follows the following steps when releasing a new version of the software:

   Open Development => Pre-Releases => Release-Candidates => Final Release

Open Development

Anyone with write access to the SVN repository can submit changes at will, including new features (on the main development trunk) and bug fixes (on the main trunk and on all SVN branches).

Any incompatible changes should be clearly documented, and only introduced at "major" releases (rather than as part of bug-fix patch versions) and is subject to a minimum requirement of a +3 vote on the -coders list.

Any other alteration for which a backwards compatibility mode exists but is off by default should be discussed beforehand on -coders and is subject to a +1 vote for going forward.

Other changes do not need prior agreement (although significant new features should probably be announced afterwards and ideally their architecture discussed beforehand).


The Pre-Release phase marks the start of the process for releasing a new version of the software. During the period between the first pre-release being made available to the first release-candidate being made available:

Pre-Release packages use a numbering scheme of Version.Number.preN (e.g. 5.3.pre1). The Pre-Release phase generally lasts for 2-3 weeks, typically with one pre-release being issued each week. The exact length of the Pre-Release phase, and the timing of pre-release versions is at the discretion of the Release Manager.


The Release Candidate phase is intended to mark the end of active delopment for a particular release version. The aim is that the final released version should be ideally identical to the last Release-Candidate issued. However, any patches approved by a +3 vote may be applied before the final release by the release manager. During the period between the first release-candidate being made available and the final release being made available the following goals and guidelines are suggested (but +3 voted patches will always take precedence):

Release-Candidate packages use a numbering scheme of Version.Number.rcN (e.g. 5.3.rc1). This phase lasts until the Release Manager, with the input of the active developers, judges that the software is sufficiently stable to be properly released (i.e. no show-stopper bugs have been reported).

While testing is expected (and encouraged) throughout the full development and release cycle, it is particularly important during the Release-Candidate phase. There is an expectation that "make test" (at the very least) should have been run (successfully!) on all supported systems - and as many others as the combined community can lay their collective hands on.

The length of a release cycle phase should be at least 1-2 RC releases in length, with about one RC release per week, and is subject to the judgment of the Release Manager. A +1 vote is needed to force another release-candidate if the release manager wasn't planning on issuing another one.

CFV processing during the RC phase is augmented by an active developers belief that a patch is sufficiently acceptable to apply even before a final release. If no further RC releases are planned, then an active developer is suggested to potentially place multiple votes on a patch given each of the following criteria:

Final Release

Despite the above policy of rigorous, exhaustive and largely fictional testing, a new final release is invariably followed by an avalanche of problem reports - some trivial and/or very specific to a particular environment, others more widereaching and serious (possibly verging on catastrophic). We've been known to accidentally alter the moon's orbit.

During the period immediately following a release, the project must be ready to respond to such problems, and possibly issue an updated version of the software with minimal delay. To this end:

Resolving Disputes

The voting system described above is intended as the primary mechanism for resolving differences of opinion. If this proves insufficient, disputes will be resolved based on the following order of precedence (the later in this list trumping the earlier):


Much of this document was originally proposed (and edited and re-edited and made better and ...) by Dave Shield. If it wasn't for him I would have just written "be good" and you'd have a lot less to read.


We're all friends generally, but just to be clear: attempts to misuse this policy will be severely frowned upon.