On Sat, Apr 14, 2018 at 4:34 PM, Nick Kew <n...@apache.org> 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. >
It's not like distros pick up patch releases anyway. They backport fixes to whatever they "froze" to upon first release, and that's it. Debian and Ubuntu, for instance, just pick the latest PHP that's released at the time the freeze for a version happens, and that's it. >>> 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. https://lists.apache.org/thread.html/9afe84b5c2e7691f0190210e2377a6d504a6a77ff1481812f44f65d4@%3Cdev.httpd.apache.org%3E >>> - 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). > > Frequent x.y.0 releases devalue that promise unless we extend it to x.(y+m).*, > which would in turn push us into new x.0.0 releases, and raise new questions > over the whole organisation of our repos. > > I’m not saying you’re wrong: in fact I think there’s merit in the proposal. > But it would need a considered roadmap from here to there. Well, one important thing to keep in mind is that a x.y.0 release doesn't preclude the x.(y-1) series from receiving fixes. Users don't have to update immediately if they're using third-party modules, as there would still be bug fixes for a while, and eventually only security fixes, before the x.(y-1) series would be fully EOL. PHP has a very predictable timeline for this: http://php.net/supported-versions.php It's also worth noting that with more frequent x.y.0 releases (say, one per year), it's likely that internal changes will be a lot smaller and more incremental. PHP is in a similar situation to HTTPD with its extensions system, and extensions that worked with PHP 7.0 either compiled fine against 7.1 and later 7.2 out of the box, or required only very few modifications. David
