On 04/14/2018 04:34 PM, Nick Kew wrote: > >> On 14 Apr 2018, at 14:48, Jim Jagielski <j...@jagunet.com> wrote: >> >> IMO, the below ignores the impacts on OS distributors who >> provide httpd. We have seen how long it takes for them >> to go from 2.2 to 2.4... I can't imagine the impact for our >> end user community if "new features" cause a minor >> bump all the time and we "force" distributions for >> 2.4->2.6->2.8->2.10… > > Chicken&egg. httpd version numbers creep in a petty pace from year to year, > and packagers do likewise. Contrast a product like, say, Firefox, where major > versions just whoosh by, and distros increment theirs every few months. > >> Just my 2c > > Indeed, a change needs to be a considered thing, and there are issues. > >>> On Apr 13, 2018, at 2:28 PM, David Zuelke <dzue...@salesforce.com> wrote: >>> >>> Remember the thread I started on that quite a while ago? ;) > > Nope. > >>> - x.y.0 for new features >>> - x.y.z for bugfixes only >>> - stop the endless backporting >>> - make x.y.0 releases more often > > An issue there is the API/ABI promise. We are a stable product, and one of > our > virtues is the guarantee that a third-party module written for x.y.z will > continue to > work at both source and binary level for x.y.(z+n).
This is the biggest issue here and where we need some way to keep this promise for a longer time. Especially commercial module suppliers are extremely slow there, even if a recompile of their source against the new version would already do like it did in many cases during the 2.2 -> 2.4 transition. I am not sure currently how our user base looks like: 1. How many take it from OS distros? 2. How many take it from sources that deliver the latest 2.4 or compile themselves. 3. How many use closed source 3rd party modules that need long term API/ABI promises? Regards Rüdiger
