It's fair to reiterate first that most folks here don't care and "get it"... but let me offer another perspective that folks may have to deal with. Devil's advocate here, and all that.
1.2.4 is released. It contains security fixes 1.2.5 is burned during RM 1.2.6 is burned during RM 1.2.7 is released. It contains bug fixes 1.2.8 is burned during RM 1.2.9 is released. It contains security fixes Let's say I choose not to build and deploy 1.2.7 since I am not using any of the modules the bug fixes address. To the uneducated eye (AKA: the auditor, the security engineer not familiar with httpd's versioning idiosyncrasies, the manager, etc), it may appear as a serious lapse in patching if five releases were between deployed versions. "9 is MUCH higher than 4! What have you been DOING all day?" they might ask. Another angle is the unspoken angst of upgrading five point releases versus one point release. It *shouldn't* be scary... but it can be for someone who doesn't fully trust us to avoid releasing regressions. Granted, both represent shaky logic that can be fixed by RTFM... but are things I've seen in the field (and have answered with a 301 to the CHANGES file). -- Daniel Ruggeri -------- Original Message -------- From: Eric Covener <[email protected]> Sent: September 29, 2017 7:16:51 AM CDT To: Apache HTTP Server Development List <[email protected]> Subject: Re: [VOTE] Release Apache httpd 2.4.28 as GA On Fri, Sep 29, 2017 at 6:57 AM, Reindl Harald <[email protected]> wrote: > > > Am 29.09.2017 um 12:35 schrieb Graham Leggett: >> >> On 29 Sep 2017, at 12:25 PM, Reindl Harald <[email protected]> wrote: >> >>> it's not about cheap - it's just questionable that after 2.4.12 the next >>> release is 2.4.16 because it looks not really sane >> >> >> Looks perfectly sensible to me > > > in your world where you know the background, without the context it looks > like "are they not capable to count?" What kind of user do you think this confusion affects? They'd have to care that N-1 wasn't released, but not be reading the changelog. -- Eric Covener [email protected]
