[Libevent-users] Plan for backporting bugfixes to stable releases

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

Hi, all!  Here's a thing I wrote up to try to explain a proposed
policy for what to backport to 2.0.x once it's stable, and what to
backport to 1.4.x after 2.0.x is released.  Absent major problems with
it, the current Libevent core developers are probably going to stick
with this for official releases, though of course nothing is written
in stone.

In other news, we have had almost no bugs found in 2.0.9-rc so far.
Absent big issues getting discovered, we'll probably be releasing
2.0.10-stable some time in the next week or two.


Plan for Libevent stable releases
=================================

Scope and disclaimer:

  This describes the plan for Libevent stable releases starting with
  2.0.x and with versions of 1.4.x-stable released _after_
  1.4.15-stable.  It has not consistently been applied to earlier stable
  releases.

  Libevent is not a huge or terribly bureaucratic project, so this plan
  is just an educated guess about what I think will work for stable
  releases in the future. It represents aspirations, not a guarantee.

Goals:

  There are two reasons to have a written policy for stable releases.
  One of them is to make Libevent easier to use; the other is to make
  Libevent easier to develop.

  Using Libevent gets easier when people know how long a release will
  get support; when people know which release series are stable to use;
  and when people can be reasonably sure about the risks (if any)
  involved in upgrading with and between release series.

  Libevent is easier to develop when people don't have to think too
  hard, upon encountering a new bug, about which releases should get it
  fixed; when we avoid destabilizing stable releases by backporting
  things needlessly; and when we can say, "No, that release is too old"
  with a good conscience when somebody asks us to fix a crash bug in
  1.2 or something.

How long to maintain stable releases:

  Libevent is developed in "release series" such as 1.3x, 1.4.x, 2.0.x,
  and 2.1.x.  Each release series starts out in alpha and eventually
  becomes "stable".

  A release series can become "stable" when there are no known bugs or
  regressions that should keep people from upgrading from the last
  stable release and using the new one.

  We should maintain at least one stable series at all times.  Because
  time and resources are limited, we can't maintain any stable series
  forever.  As a compromise between user convenience and developer
  convenience, I suggest that we should support each stable series for
  one additional year after it is no longer the most recent stable
  series.  For example, as of this writing, 1.4.x is the most recent
  stable series.  If 2.0.10-stable is released on December 15 of 2010,
  2.0.x will be the most recent stable release, and we will support
  1.4.x at least until December 15, 2011.

  This gives an upper bound on a stable series's lifetime.  For a lower
  bound, I suggest 2 years.  In other words, if 2.0.10-stable is
  released in December 15 of 2010, we will support it until December 15
  of 2012, even if 2.1.x-stable is released in June of 2011.

Scope of maintenance for stable releases:

  Every change to a stable release carries a risk of itself having bugs,
  so we want to be careful about what we backport to stable releases.
  This holds especially true for releases older than the more recent
  stable release, since users who are staying with them are probably
  more concerned with stability than are users who have upgraded.

  Here are some proposed requirements for changes to stable, loosely
  adapted from the Linux Kernel's stable_kernel_rules.txt

  For *ALL* changes to stable:
    - The patch must be tested and correct.
    - The patch must fix one thing and one thing only.  (This makes
      it easier to bisect regressions, and makes it easier to review
      changes.)
    - The patch must fix an actual bug.
    - The patch should not add new features or APIs.
    - The patch must not break any existing code using the APIs as
      documented.
    - The patch should not break any existing code unless absolutely
      unavoidable.
    - The patch should not change the ABI unless absolutely
      unavoidable.

  For changes to the *MOST RECENT* stable:
    - The bug fixed must be an actual bug that could affect a program.
    - The size and complexity of the fix must be proportional to the
      severity of the problem.  Huge rewrites to solve minor issues
      aren't okay.  Diffs that are longer than 100 lines (excluding
      tests) should be ones to fix really serious issues.

  For changes to *OLDER* stable releases:
    - The patch should fix a _critical_ bug: a security hole, a
      problem that affects real code with no reasonable workaround,
      a build failure, a regression, or something like that.
    - The patch should not be big or complex.  Any diff over 100 lines
      (excluding unit tests) is probably too big.  Complexity is, alas,
      subjective.
    - The patch should be *thoroughly* tested and *obviously* correct.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.