Suricata development has a yearly cycle of one major release a year, and about five to six minor releases a year. In addition, for the development branch we’ll do at least a beta and a release candidate.

In our version scheme of ‘x.y.z’ (e.g. 3.2.1, 4.0.0), we bump ‘x’ once a year. ‘z’ is bumped for every minor release.

A minor release should always be safe to install. The major releases have more room for introducing breaking changes, even though we try to minimize breaking changes in any case.

We typically end-of-life (EOL) a branch when the branch that should replace it is ‘stable enough’. This normally means that when x.y.1 or x.y.2 point releases are out, the previous stable branch is scheduled to be EOL’d.

For example when going from 3.2 to 4.0, this is what the process will look like approximately:

3.2 - 3.2.1 - ... - 3.2.3 - 3.2.4 EOL announce - 3.2.5 EOL
             4.0dev   -   4.0 -  4.0.1 -  4.0.2 - 4.0.3
                                                 4.1dev ...

When we consider the ‘new’ stable branch to be good enough, we will announce the EOL date for the ‘oldstable’ branch. The actual EOL date will then be 2 months from the announcement date.

States for a branch: development -> stable -> oldstable -> EOL

Current EOL Status

  • 6.0.x: supported
  • 5.0.x: supported
  • 4.1.x: supported. EOL on December 31st, 2020
  • 4.0.x: end of life starting May 7th, 2019
  • 3.2.x: end of life starting December 18, 2017
  • all earlier versions: end of life

We strongly recommend updating to a supported branch if you’re still running an older version.

EOL Announcements

EOL announcements will be done by an email to the oisf-announce list and by a post to the forum. They will list the end date of the branch involved.


There are a number of reasons for this EOL policy. First maintaining parallel branches is a big burden on any team. At any given time we already maintain at least two:

  1. stable branch and development branch, or
  2. stable and ‘oldstable’
  3. for a short period also ‘stable’, ‘development’ and ‘old stable’.

The 1st phase is the most common and is during the main development effort of the next major version.

Second, we feel that the nature of our product requires fast moving development and frequent updates. Our field moves quickly, and we need to add new protocols, logging options and detection capabilities all the time. Next to this OS’ are updated, development tool chain is constantly updated, etc.


Sometimes people ask for a Long Term Support (LTS) version, where a single major release would be maintained for a much longer period. We can see some value in it, but the cost would be significant. So at every SuriCon we’ve asked the audience if we should do a LTS version of Suricata. The answer has  consistently been ‘no’.

One might argue that visitors to the conf keep up to date, so we also asked vendors that we know integrate Suricata. They too said ‘no’. They mention that keeping up to date by doing major updates about once a year is acceptable to them. Some distributions like Debian don’t do version updates in their stable releases.
Sadly this leads to almost all their security tools being out of date, often dangerously so. Here things like special ‘update’ or ‘backports’ repo’s, or repositories maintained by OISF itself can help. The Ubuntu PPA OISF maintains is an example of this.

What would it take to do an official LTS release?

The simple answer is funding. For OISF to commit to a LTS release of 2, 3 or 5 year or so, we need to be able to have someone working on it. This means there is a financial commitment.

We estimate this at about USD 100k/year.

Of course a lot depends on how long an LTS branch would be maintained, what sort of work would and would not be done and how many of these branches would exist in parallel.

This cost is for:

  • developer time for backporting fixes and sometimes fixing unique issues
  • keeping QA up and running for the older version & triaging new QA tests on LTS branch
  • evaluating all bug reports for LTS version
  • time for supporting the LTS version to end-users and integrators
  • doing releases
  • management overhead for this person, including travel, training, etc

OISF would be happy to talk to an organization that is willing to fund this effort. Please contact us at