On 1/22/2012 9:20 AM, Jim Jagielski wrote: > Seems to me that there's enough to warrant a 2.2.22 release... > As long as we're doing a 2.4.1, why not also provide a 2.2.22 > at the same time?
Because, 2.4.x is a distraction to shipping 2.2.22. You are welcome to do a 2.4.x, although I will vote against it without sensible include/includeoptional behavior, or without a sensible non-DoSing core filter, or without the correction of sometimes faulty acceptfilter none/mod_ssl behavior on win32. Only one of those is a serious security issue you are ignoring, and that would only be one vote against, which certainly doesn't prevent its release. I had expressed my intent, as you well know, on the security and private lists, to RM 2.2.22 the moment the last security patch is in place (using the same autogunk tooling so that users have no surprises in upgrading). And I am still committed to helping out by doing so. Or maybe you didn't know... I do suggest you review the open defect threads on security and dev w.r.t. 2.2.22-dev and 2.4.1-dev because the current list precludes any sane tag and roll of either. Sorry if I assume you had read messages that you hadn't scanned. You are welcome to do an earlier 2.2.x tag which I will vote against for shipping known-vulnerable software. Of course, that is only one vote against, and certainly doesn't prevent its release. Of course with 2.4.x, I hope you are going with the most modern autoconf/libtool tooling, since there is nothing forcing a user to adopt it, and any config defects will shake out soon enough. My attitude towards maintaining consistent tooling for 2.2.x src tarballs is entirely related to ease-of-mandatory-transitions.
