> 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

Reply via email to