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

Our version scheme follows a pattern of ‘x.y.z’ (e.g. 3.2.1, 4.0.0), in which 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.

A branch is typically designated as end-of-life (EOL) 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 the ‘new’ stable branch is judged 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: end of life starting August 1st, 2022
  • 4.1.x: end of life starting 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. These announcements will list the end date of the branch involved.

Rationale

There are a number of reasons for this EOL policy.

First, maintaining parallel branches is a heavy burden on any team. At any given time we already maintain at least two:

  1. a stable branch and a development branch, or
  2. a stable and an ‘oldstable’
  3. or, for a short period, a ‘stable’, a ‘development’ and an ‘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, operating systems are updated, development tool chains are constantly updated, etc.

LTS?

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. At every SuriCon we’ve asked the audience if we should do a LTS version of Suricata. The answer has consistently been ‘no’ up to this point.

We understand that conference attendees are among the most up to date, so we also asked vendors that we know integrate Suricata. They too said ‘no.’ For them, an annual major update is acceptable. In addition, some distributions like Debian don’t do version updates in their stable releases.
Sadly this can lead to almost all their security tools being out of date, often dangerously so. In this case, things like special ‘update’ or ‘backports’ repos – repositories maintained by OISF – can help. The Ubuntu PPA that 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 would need to be able to have someone working on it. This means there is a significant 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 comes from:

  • 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 info@oisf.net.