Re: Remaining breakage on apr-1.7.x branch

On Thu, Jul 28, 2022 at 12:59 PM William A Rowe Jr <[email protected]> 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.