Hi! > That's not quite how it works; the distro package maintainers maintain a > sort of forked version of upstream code, combining a well-tested > upstream release with a set of patches, many of which will be backported > fixes from newer releases. So the current package in Ubuntu 14.04 LTS > [see http://packages.ubuntu.com/trusty/php5] is "5.5.9+dfsg-1ubuntu4.7", > and the Ubuntu Changelog shows 12 releases, mostly for security patches, > which is nearly as many as there have been upstream releases.
I think this is all wrong, because I don't see how they can do better testing with random set of patches than with real release version, but that's beside the point. The point is it's very easy to make a deployable package from php.net source pack, but it's much harder to move an organization to different version that may cause BC breaks and other disruption. It's both technical and organizational - try to propose moving software from version 5.5.23 to 5.5.24 and from 5.x to 7.x and ask anybody which is riskier. Almost universally you'd be told the latter is much riskier. > This is a straw man as far as the points I made are concerned. I'm > talking about the risk of switching from 5.5 to 5.6, which is pretty low. Switching to 5.6 would be useless since what is being propose it to ban any enhancements up to 7.1. > Well, you could fork the JSON extension, I guess. But yes, not all > options are available in all cases. For most enhancements, no options but "wait for a couple of years" are available unless you want to maintain a full-blown php fork. > That's completely the opposite of what I said. I said I *do* think > adding small features to 5.6 may be justified, since 7.0 will be a more > painful upgrade. Then we agree. But the proposal here was to ban all enhancements in released versions. This is just wrong, and I am glad you support it. > The type of backporting I'm questioning is adding features to 5.5.x, > when we have 5.6.x released, and 7.0.x in preparation. And, *after* the > 7.1.0 release towards the end of next year, I would not expect features > to be backported to 7.0. Depends on "features". In principle I'd be fine with enhancement going only into 5.6, but given its abysmal adoption so far, practically I can see the case for some stuff in 5.5 too. But I recognize it's chicken and egg problem, so if we can reach consensus on 5.6, I can live with that. > No, indeed. There, the cost is only on the developer having to ensure > that they don't deploy code relying on the new option to a server one > patch version too old. This is a regular "version requirement" concern which ops should be well familiar with and be able to handle. > prefixes like error_*, file_*, etc. So, for simplicity, you might as > well treat the global namespace as out of bounds. In my code, I'd be wary of putting non-prefixed functions into global namespace. PHP versions is only one reason - if two libraries have error_report() function, they never can be used together, not a good thing. I'd rather call it my_library_error_report() if for some reason I can't namespace it properly. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
