Hello friends and collaborators, I'm still rather certain this change is ABI and API contract-breaking on the apr-1.7.x branch, which holds the project hostage for providing a well-understood security fix on the legacy branch. Such things can't persist, our individual maintenance branches must also observe semver, such that anyone could consume a maintenance branch and not be API nor ABI broken against the prior sub-version release;
https://github.com/apache/apr/compare/1.7.0...1.7.x#diff-86c28ef8e95257a8d60ce73f3262290e91fc5ca3eb722144a6c99559ddf717cf I'd propose a radical solution, either all of include/* excluding most of private / arch/* have no adverse effects on a rebuild, or we revert the whole branch to the last stable release, in 7 days. Allow a 7 day window to reintroduce critical and desired changes that don't break our dev guidelines; https://apr.apache.org/versioning.html. All other questions were resolved at least 4 weeks ago, as can be observed from include/* changes which alter the incremental consumer's observations, github makes this simple; https://github.com/apache/apr/compare/1.7.0...1.7.x# So I think we are nearly ready 14 days from now to tag 1.7.1 and solve this conundrum. If it can be proven than the existing 1.7.0 or 1.7.1 builds would be entirely compatible and not break developer's expectations when deployed against either 1.7.1 or 1.7.0 in the next 7 days, my objection is withdrawn and we will tag this code in one week, not waiting for 2 weeks. Who wants to help prove up or down that it should persist and work out the back-out as needed? Otherwise I ask the project member's permissions to work from a new 1.7.x-rebuild branch for the following week based on 1.7.0, and replace 1.7.x with the 1.7.x-rebuild branch one week later. I hope none of us are looking to land in this quicksand again, Bill
