Hopefully we aren't waiting any longer for 1.8.0 than 1.7.1, so that shouldn't be a real risk
On Thu, Jun 30, 2022 at 7:02 AM Yann Ylavic <ylavic....@gmail.com> wrote: > > On Wed, Jun 29, 2022 at 6:09 PM Yann Ylavic <ylavic....@gmail.com> wrote: > > > > By making such impracticable policies for revision changes (semver > > sense), we are going to simply not fix anything but trivial changes > > without bumping minor, and no one would/should care about the old > > (though still "maintained") minor versions. What's the point of > > releasing 1.7.1 then? Let's go with 1.8.0 only, simpler (less > > maintenance) and better for everybody.. > > OK, by re-reading this I realize I was a bit harsh, a bit of > frustration here (fixes that don't get in..), sorry about that. > > After a bit of diving into svn history, this commit was mainly to > address UAF with apr_thread_pool code when it was using detached > threads, which is not the case anymore (r1884110, r1889219). > So the scope of the fix might be for user detached thread usage "only" > (which may not be common), and APR_POOL_DEBUG (which is mainly never > by devs only, though something happening in APR_POOL_DEBUG mode might > happen without when the planets are no longer aligned). > I'll try to revert and see how it goes for, e.g., httpd's ci (where > mod_watchdog uses thread pools). > > Anyway, if we get bug/crash reports for 1.7.1 and some (time > consuming) invertigations shows that it's fixed in 1.8, I'm going to > be a bit frustated too ;) > > > > > Regards; > > Yann.
