On Thu, Jul 28, 2022 at 12:59 PM William A Rowe Jr <wr...@rowe-clan.net> wrote: > > 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.
Should we just back out r1896748 (ring strict aliasing thing) out at this stage? I think the radical solution is too labor intensive and unlikely to progress.