> 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). 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. — Nick Kew
