Hi! > I tend to agree that it would be easier for all parties if we stop > adding stuff in micro versions, as it is easier to remember and
I don't think it is a good idea. Imagine you are a PHP developer working on a project, and you noticed there's some small functionality missing that would improve things a lot for you - like parameter to some function or returning some value that is missing. You could easily contribute it, but if it can't go in minor version there's no point for you to even bother. Because even if your org is super-up-to-date, they run 5.6, most realistically - 5.5, and if it's like the majority - it'd be 5.4 and worse. You could hope to convince your bosses and your ops to go to 5.6 and keep it reasonably updated within 5.6, but if the only addition you can make is 7.1, it's the lost cause - by the time your org could go to 7.1 your project will be long done (or at least long designed to work without this new feature) and you may be already working in another company. Yes, we have releases (almost) each year, but adoption of them is much slower, and with all BC breaks in 7.0 it would probably be even slower when going from 5 to 7, so this means doing small improvements to PHP is essentially of no practical value for PHP developer since there's no chance this improvement can be used in the lifetime of a typical project. I do not think it would be good for PHP. > As everything can be considered as beeing a BC break for at least > someone on Earth, I admit it is hard to understand the meaning of "small > self-contained additions in a micro version" :-p I do not think we should consider adding functions/options "BC break", not by any sane definition of it. Of course, nothing prevents somebody from using insane definitions, but it's of no concern to us. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
