Nick Mathewson <ni...@freehaven.net> wrote Sat, 20 Nov 2010 03:25:05 -0500:
| 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'm for the second one of these. Regression in a library is bad and the worst kind is the one which never shows at compile time and breaks programs in mysterious ways at mysterious times. Bad efficiency can often be detected as such and if there's a tweak the program can do in order to improve it, this is less of an issue than functional regression. Of course there's a risk of regression because this backend has been less tested but that can be addressed beforehand, given that the release schedule isn't pushing declaring stable too hard. (I say this not as a 1.4 user worried about regression but as a 2.0 user happy to have found a piece of software with high enough kernel insulation that I'm willing to take on the responsibility of a multiplatform library doing I/O.) _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://lists.monkey.org:8080/listinfo/libevent-users
