Hi, Am 01.04.2015 um 22:36 schrieb Stanislav Malyshev: >> Debian, Ubuntu and CentOS: ~21,23% >> >> (I assume here like Anthony that the installs matching a distribution >> specific version always come from that distribution). > > Pretty big one, I'd say, but even with this one you only get 1/5. Also, > as I said, it's very easy to take distro package and repackage it to use > the source from the same minor but up-to-date patch version.
As I said, I miss-remembered the numbers to be much higher. >> An addition and a bug fix are different things. > > I know but you said, I'm quoting, "please let the x.y.z versions contain > only additional (security) fixes" which excluding non-security fixes too. I tried to indicate with braces around security that general non-security fixes may be allowed to, but I try to be more explicit next time ;-) > Let's consider a somewhat arbitrary example: > https://github.com/php/php-src/pull/1211 > > There's a HTTP status code needs to be added (doesn't matter if new or > just omitted by oversight). You could have it in next 5.6 version (you > can have it in use in 3 months realistically - one month for release to > catch up, 2 months for ops in your project to be confident that new > patch release doesn't break anything) or you could have it in 2.5 years > (1.5 years for 7.1 to be released, 1 year - and that's *extremely* > optimistic - for ops to be ok to switch to a new distro version which > hopefully - just hopefully, extremely optimistic again - but that time > ships with 7.1 and not still randomly patched 5.5). The questions here are: * will this code break any code running with PHP before that patch? * does this code change the language in any way? if any of this is true, I would consider the patch not self-contained any more. > For me, it sounds insane that you'd have to wait for so long for such a > simple thing. > > Of course, instead of status code it could be option support in XML, or > new function/option support in ICU, or new connection option in mysql. > Any improvement in the environment - do you want it in PHP in terms of > several years or in terms of 3 months? But then using the x.y.z version schema implies something like semver but in reality we have more like a rolling release. Instead we should consider having a stable "PHP-next" nightly release that is something like a stabilized master that gets all changes for the X.Y+1 release. If you require these little features, you use that, if you only require security/bug fixes, you stick to the regular x.y.z releases. Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
