On 3/23/2016 7:27 AM, Jim Jagielski wrote: > Release Often is hardly a Bad Thing, at least IMHO. When the > time is right for a release, then we release. It seemed a > good time, again IMHO.
Kinda late to the party, but shouldn't what's committed to a stable branch _always_ be ready to release? Just my .02 on the side conversation. As a sysadmin, I have no strong preference for release often versus release seldom... just so long as what is released is stable and won't break my stuff. At $dayjob where I have to answer to regulatory and audit authorities, there have been plenty of releases of various software platforms that I have chosen not to pursue because they don't address anything I need to worry about. No harm done. So, my stance as a sysadmin (and probably a fairly common stance, I'd guess) can be summarized as: If there's a bug fix for a problem I'm seeing, I'd really like the release sooner rather than later. On the other hand, if there's a security fix, I need it released immediately. On yet another hand (because it seems I have three), if the release has nothing I care about... then I don't care. But whatever happens, don't break my configs :-) As an even further side note... after following this dev list (community) as long as I have, I'd happily put an httpd 2.4.nightly against just about any other released software. I can't think of a single case where something got *committed* to 2.4 that would break my configs let alone something that got formally released. Indeed, the few thousand httpd servers I run haven't been harmed by a release in all of my time as an admin (1.3, 2.0 and 2.4 alike). Our release process is, indeed, pretty damn good. So whether we release often or release seldom, we can at least hold our head high while we do it. -- Daniel Ruggeri
