[syslog-ng] syslog-ng OSE supported versions, EoL times, etc

[Gergely Nagy]

Hi!

We've been thinking about how to approach the problem of supporting
syslog-ng OSE versions, the end-of-life of them, and related issues.
I've been maintaining syslog-ng branches for about a year and a half
now, and the time and effort required to do that is only becoming clear
now that I have a reasonable sample size.

There was no clear communication about how long each version of
syslog-ng OSE would be supported, and when they will reach their end of
life, which made it harder for distributions and pretty much everyone
else to plan ahead and schedule time for migrating to a new version.

We intend to rectify that now, and my plan is outlined below:

We would - at any one time - maintain four branches of syslog-ng
(including the bleeding edge development branch). The other three would
be: a critical-bug-fix-only maintenance release (this is currently 3.3),
a recommended stable release (3.4), and the upcoming feature release
(3.5beta at the moment). Whenever the development branch gets a beta
release, it would automatically become the upcoming feature release, the
former feature release would get promoted to stable, and the former
stable becomes the maintenance branch.

In this scheme, 3.3 would be maintained until 3.6.0beta1, at which
point, it would be dropped from the supported set, and 3.4 would take
its place, and 3.5 would become the recommended stable release.

Of course, it's still hard to plan ahead without dates, but dates are
something I cannot give at this point. The best I can do is send an
announcement once 3.6 hits the alpha stage, and give a rough estimate on
when it would hit beta. That's a few months in advance, and by that
time, 3.4 will be out long enough for folk to migrate over, thus 3.3
shouldn't be in much use anymore.

With the current pace of development, this means that a syslog-ng OSE
release will be maintained for about 2-2.5 years, and I expect it will
not go down by much more than half a year, meaning 1.5-2 years of
maintenance.

And to make it clear what each branch means, let me expand on that a
bit:

* Maintenance: The former stable branch, which receives critical bug
  fixes only. People are strongly encouraged to migrate from this to the
  stable one, but the branch is still supported to some extent, to make
  it easier for distributions, among others. Critical bugs are security
  issues, serious regressions, and so on - I reserve the right to decide
  which bugs to consider critical. Fixes from any other branch are not
  backported, unless they're critical.

  Currently the 3.3 branch fills this role.

* Stable: The stable branch, receiving all kinds of bug fixes, including
  smaller fixes backported from newer branches (including the next
  feature release and the development branch too). It may also receive
  very small features too, which do not affect the package as a whole:
  things like the $(format-json) improvement to allow comma-separated
  scopes, or being able to specify a template for the JSON parser.

  Currently the 3.4 branch fills this role.

* Feature: The next stable branch, which we consider stable enough, but
  has not received as wide testing as the stable branch yet. This gets
  the most attention, as the idea is to stabilise it as soon as
  possible. Other than being newer than the Stable branch, this is
  treated in exactly the same way.

  Currently the 3.5 branch fills this role.

* Development: The branch where all development happens. While we try to
  keep it stable, regressions and breakage is more likely here, and new
  features are not guaranteed to remain the same during the development
  cycle, so building production on this branch is not advised. New
  features are developed against this branch, and the Incubator's[1]
  master branch follows the development branch too.

  The 3.6 branch will fill this role, once opened.

As for the Incubator[1]: it will only have two branches: one for the
latest feature release, and another for development. Maintenance and
Stable versions of syslog-ng will not be supported in there.

 [1]: https://github.com/algernon/syslog-ng-incubator

The Incubator is a place for experimental modules that are either not
ready to be merged into syslog-ng proper, or are kept separate for any
other reason.

-- 
|8]