Suricata has a fast ‘release quickly, release often’ development model where we do two major releases a year.
In our version scheme of ‘x.y.z’ (e.g. 3.2.1, 4.0.0), we bump ‘x’ once a year. Additionally, we bump ‘y’ once a year as well.
We consider both pretty major releases, where the ‘x’ has more room for breaking changes, even though we try to minimize breaking changes in any case.
We typically 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 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
- 4.1.x: supported
- 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 will be done by an email to the oisf-announce and oisf-users email lists. 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:
- stable branch and development branch, or
- stable and ‘oldstable’
- 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 a 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
The OISF would be happy to talk to an organization that is willing to fund this effort.