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

[Nicholas Marriott <nicholas.marriott@xxxxxxxxx>]

Hi

Obviously it is ultimately up to you how you want to support things but
I'd just say that with a limited development team it is probably best to
avoid hard and fast support commitments.

I think a lot of small open source projects get bogged down in writing
and following rules and policies when there is a lot to be said for just
dealing with it on a case-by-case basis.

I'd personally make the judgement on when to drop 1.4 on when the time
seems right rather than a hard time limit. I think it should depend
things like uptake of 2.x, how many issues are still being raised for
1.4 that can't legitimately be told to go away and use 2.x, when you
want to more pointedly encourage stragglers to upgrade, etc.

libevent is small and clean and has a good license, so it is easy for
anyone to maintain their own copy and backport whatever they like. I
know places doing this and although I suspect they will still be using
1.4 long after December next year, the fact it is no longer supported
will not matter at all.

Personally I'd rather libevent developers spent their time pushing the
release branch forward than putting too much effort into supporting
older branches.



On Fri, Dec 10, 2010 at 10:45:33PM -0500, Nick Mathewson wrote:
> 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.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.