httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reindl Harald <h.rei...@thelounge.net>
Subject Re: Reset out x.minor.z definition of 'minor' at httpd?
Date Thu, 26 Jan 2017 05:29:16 GMT

Am 26.01.2017 um 00:20 schrieb David Zuelke:
> On 20.01.2017, at 21:37, Graham Leggett <minfrin@sharp.fm> wrote:
>>
>> On 20 Jan 2017, at 7:47 PM, David Zuelke <dz@heroku.com> wrote:
>>
>>> I'd actually like to question the whole practice of porting features back to
older branches. I think that's the core reason why trunk is in total disarray, and why no
substantial releases have been made. There is just no reason for anyone to push forward the
state of 2.6 or even 3.0 if you can just backport whatever you want.
>>
>> The reason this is bad is because Apache httpd comes with a module ecosystem - when
you move from httpd v2.0 to v2.2 to v2.4 to v2.6, or rules are that the ABI can break, and
therefore all modules that depend on that version must be recompiled. This includes modules
that are closed source and offered by a proprietary vendor, or are open source but provided
in binary form by a distro.
>
> Yeah, I hadn't considered proprietary modules.
>
> To take the PHP example, ABI and API changes are usually minimal, so most extensions
build pretty cleanly; if not, then they can be fixed, and with most stuff on GitHub these
days, that's usually a PR away. Development cycles of extensions have definitely sped up together
with the language runtime.
>
> Do people who run a non-distro httpd really install distro-provided modules though?

yes - i build httpd, mod_security, apr, php, pecl-extensions from source 
(own rpm packages) but don't want to maintain the whole subversion 
package and it's build-dependencies too (mod_dav_svn)

but on the other hand in that case i won't jump to the next httpd 
release until the distribution (Fedora) does, at least not for a larger 
timeframe than prepare the upgrade on a testing vm

Mime
View raw message