SOFTWARE SUPPORT POLICY

General

NLnet Labs is a non-profit foundation founded in 1999. We are recognised by the Dutch tax authorities as Public Benefit Organisation (Dutch: Algemene Nut Beogende Instelling or ANBI), which is the equivalent of a 501(c)(3) charity in the USA.

Dutch tax regulations allow us to have reserves that guarantee two years of continued operations in case all industry funding would disappear. Thus, in the unlikely event that NLnet Labs can no longer commit to maintaining our software projects, we will announce this at least two years in advance.

Strategy

Our software development strategy is designed to be clear and simple. All our software projects and libraries are open source with a liberal license, either using the BSD 3-Clause License or the Mozilla Public Licence 2.0. Each project has at least two dedicated developers.

NLnet Labs will only develop functionality that is going to be part of the main branch of the software. We do not maintain special forks, nor do we offer Development, Stable, Extended Support or Subscription versions of our software.

Versioning

NLnet Labs adheres to the straightforward, semantic versioning scheme that is commonly used in the software industry.

Major Version

Main release version of the software indicated by the first digit in the version string (e.g. 3.x.x).

Minor Version

Minor release of the software indicated by the second digit in the version string (e.g. x.1.x)

Patch Version

A patched release of a certain version of the software indicated by the third digit in the version string (e.g. x.x.2).

The major version will be changed when we make incompatible API changes, the minor version when we add functionality in a backwards compatible manner, and the patch version is changed when we make backwards compatible bug fixes.

Initial Development Phase

When we do an initial development release, we will start at version 0.1.0 and then increment the minor version for each subsequent release. During this phase we have the liberty of making large architectural changes, we do not guarantee backwards compatibility or a stable API. Still, minor and patch versions are applied in the same way as in the semantic versioning scheme and generally we try to accommodate compatibility and API stability as much as possible.

Once the software has reached an adequate level of maturity, we will start doing rigorous testing and code reviews. At this time we will announce and offer release candidates before a new final release is made available. We may start offering packages as well.

This means you should not be discouraged to use our software in production when the version number is below 1.0. It simply means you should be prepared to accommodate for changes to a larger degree than after 1.0. This also means we offer professional support on releases below 1.0.

Release Interval

For many of our software projects we collaborate with Operating System package maintainers. To keep this task manageable for them and us, typically we do up to eight minor or patch releases per year. The major version of our software is typically stable for multiple years.

We do not apply a strict schedule, but users should expect new versions to be released every six to eight weeks.

Supported Versions

Support is provided in respect of the latest release, i.e. releases with the highest minor and patch version level. We do not backport security fixes to older (minor) versions. In the event a new major version is released (e.g. from 3.2.18 to 4.0.0), support will also be provided on the latest minor version of the previous major version (3.2.18) for a period of one year from the release of the new major version (4.0.0).

In the event that, during this period, a new patch or minor version of the previous major version is released, then support on these versions will only be provided for the remainder of the one-year-period.