I like the idea. It took a bit of ruminating to get there, but the thought of shipping new features in odds and fixes/stabilizations in evens (or something along those lines) feels comfortable. I would personally prefer a semver release style where we burn minors often-ish, but haven't been able to comment on Eric's document yet to socialize the thoughts. This is a good compromise in the meantime.
Of course... an important part of making that work is clarifying and documenting the practice with our user community. The other part is having RMs ready/willing to do their thing more frequently. Our unpredictable and often long release cycle could cause features/fixes to get "locked up" in the branch if we don't have a conduit to get those bits to the community. I'm willing to commit cycles there, but my hope is that the automation reduces the barrier to entry for an RM and we can add to the list of ready volunteers. Indeed, I was encouraging jchampion at ACNA to toss his hat in the ring as an RM... here's to hoping :-) -- Daniel Ruggeri On October 15, 2018 9:10:13 AM CDT, William A Rowe Jr <[email protected]> wrote: >Like my beg for getting us to the 2.4.35 release tag, I'd like to >propose >we keep patches to branches/2.4.x/ generally within the scope of >straightening out the remaining quirks related to the OpenSSL 1.1.1 API >and >library behavior changes (and similar corrections for any alternate >library >implementations such as LibreSSL or BoringSSL.) > >This isn't a vote per se... just an ask whether we collectively want to >defer all potentially disruptive changes for a release following >2.4.next. >We can certainly resume with that next release on an expedited basis, >within a month or few (as opposed to waiting 6 months as has been >typical.) > >It appears that dropping in OpenSSL 1.1.1 into a previously working >httpd >built against 1.1.0 is not the "plug and play" replacement that the >OpenSSL >team originally envisioned, and deliberately building any previous >release >of httpd against 1.1.1 is similarly broken. > >Thoughts? Other concerns?
