That's contrary to how most see it, I held off replying to this thread because I wanted to put this out there, on our system admin group, which contains some 491 members from 29 countries, and includes some of the rather well known ISP and Hosting providers that are a lot bigger than a few soho admins, we are talking just one of them alone hosts over 1 million websites, as of midnight, 143 replied,with 141 said they do consider a release often approach bad
Interesting statistics, thanks for sharing. I can’t really argue with those stats but will make an attempt anyway ;-) Not to argue with the stats themselves, but to argue what they mean (lies, damned lies and statistics and all that). I am sure some sysadmins would prefer we had no releases at all. Releases are effort after all. But that also means there are no security issues to address or new features for website owners to take advantage of and I don’t think that will ever be the case for a, still evolving technology like a web server. Not addressing both of these, risks Apache httpd falling behind competitors - which I personally think is a bigger risk than users leaving httpd because it releases too often. For those that want stability over features the packaged versions managed by the various Linux distros seems to be the perfect solution. They get timely security patches but don’t have as much risk of breaking things as only take those security patches and not the feature changes. Why is that not the best option for these users that responded? This still allows the rest of us that one them, new features. As I said earlier, holding off releases of security issues because we don’t want to do frequent releases just seems non-sensical to me, so if staying with vendor-packaged versions, it makes little difference how many releases httpd do except they get security fixes earlier with frequent releases. And that can only be a good thing IMHO, even if it does create work. and have and will refuse to update unless a compelling in the wild creates reason to. That to me should always be the reason for upgrading. I don’t think it’s necessary to take every update a vendor publishes - unless it includes security fixes, in which case they should strongly be considered depending on whether those security issues affect your usage of the application (which is admittedly sometimes more difficult to figure out than just taking the patch!). As I say staying with Linux vendor packaged-version means you take the security patches only (and may take nothing from several httpd releases in a row if there are no security patches). Though, on the flip side, I do think keeping software reasonably up to date is better or you’re in for a shock when you inevitably do upgrade. You only have to look at the past few attempts (scrapped versions) to release apache to see the dangers in rush rush rush attitude. I’m assuming it’s a given that httpd should only release when ready to. I don’t think any of the release-often advocates are suggesting taking less care with releases or releasing untested code. My question is would any more testing go on if we did release less frequently? On one side I get the argument that more time between releases theoretically allows for more testing time, but I question whether anyone would use that time for that? My experience of software development (outside of httpd) suggests not. Additionally it’s very often the case that small releases reduce the risk (as little is changing) and reduce the time to fix when something does go wrong (as little has changed and it’s often fresher in the developers mind). That’s not to say that bugs don’t go for several versions without being noticed, but at least major one should be seen quickly. Saying that, the releases do take effort and do take time to test, so I don’t think httpd is ever going to be a fully automated “DevOps” process that is comfortable releasing multiple times per day. As I mentioned previous nginx seems to release once a month and that seems about right to me but others may have a different opinion. Perhaps it would be good to clarify that to make sure we are all on the same understanding as to what to goal here is? On your last point, I do think the perception of scrapping a version is bad, even if it is actually healthy for software to do this if they are not comfortable releasing it. Version numbering is cheap after all, so other than the perception there is little lost with this approach. And the alternative of being scared to scrap a version and pushing ahead with a buggy release is far worse. Nonetheless scrapping a release is seen as a bad thing, as your comment suggests so perhaps that needs to be addressed one way or another. I do think that if httpd went with release candidate versioning, like others do, it would that improve the perception here. So 2.4.38-RC1 is proposed and tested, then if bugs are found it goes to 2.4.38-RC2...etc. then once everyone is comfortable it is released as 2.4.38. This would help address the perception of “failed releases” and also allow cleaner release notes as all changes would be bundled in with 2.4.38 rather than potentially spread across multiple unreleased versions. It would also still allow control as release candidates can be seen and counted (if you reach RC99 for example without having a releasable version then you really should start to question what exactly is going on with the development here and what needs to change to get it back under control!!). In summary I can understand why you got the stats you did, but I still believe there are compelling reasons to release more frequently (within reason).
