RE: [Libevent-users] Linux, epoll, libevent, regressions, stability, and 2.0.9

["Gilad Benjamini" <gilad@xxxxxxxxxxxxxxxxx>]

> 
> Here are the two options that I *am* considering:
>   * Include both backends; make the existing changelist backend on by
> default.  The problem here is that it represents a genuine regression
> against Libevent 1.4, and I really hate having regressions.  A library
> that accepts regressions for well-formed code using older versions is
> IMO being very rude to its users, and encouraging people to worry
> about upgrading.
>   * Include both backends; make the non-changelist backend on by
> default.  The problems here are that a) the non-changelist backend is
> slower, and most people won't do whatever is necessary to activate the
> faster one, and b) the non-changelist backend has had not nearly so
> much testing as the current changelist-based backend.  If we do this,
> the lack of testing means we cannot possibly call 2.0.9
> "2.0.9-stable"; we'll need to call it "-rc" instead. :/
> 
> I am currently leaning towards the last option.  Efficiency is
> important, but even more important is knowing that if you wrote a
> program using Libevent version N, your program will still work when
> Libevent N+1 is released.  Setting an option to enable extra
> performance is more important than setting an option to enable
> backward compatibility.
> 

Generally speaking, I agree with your logic and conclusion, but with a
twist.
Both options share the problem of suggesting the right choice for a
programmer; e.g. providing the changelist-option by default and failing
compilation for programs which are not fit for it could be nice, but it's
not really possible.
You could, however, force programmers into a choice by not providing a
default. If the configuration script forced the user to choose between two
back ends you have a higher chance of people reading documentation and
making the right choice for themselves.

If that doesn't sound like a good solution, I'll go back to supporting the
last option.

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.