Hi list, I'd like to introduce thresholds of backwards compatibility breaks, i.e. maximum numbers of allowed BC breaks per version.
Lester's mail from a couple days ago had me thinking about the BC breaks that occur now and then in all the RFCs or all the mails I see these days. Now, take what I say with a grain of salt, as I've only recently been involved in this mailing list, as well as in php-src development. Let me explain my reasoning. To allow the users of PHP to upgrade their versions, and enjoy the new features, as well as the security fixes, the least number of BC breaks should get in the new released versions. That is because a BC break can lead to many hours of a codebase adaptation, hours that many companies don't want to pay for if the benefits are minimal. However, to allow us to evolve the language, BC breaks are a necessary evil. Another issue is the short timeline of security fixes for the versions. PHP 5.4 will have a total lifetime of 3 years, a very short one for many people. I'm not advising to increase this timeline, just saying that it gets in the equation of my discussion. To mitigate the issue of BC breaks, I think introducing the concept of thresholds would greatly help the PHP adoption, and mostly upgrades of PHP versions. If people know that a limited amount of work is going to be needed when upgrading a PHP version, the upgrades should be done more often. For example, the following thresholds could be used: - major BC break: major versions only. 5 major BC breaks allowed per major version. - minor BC break: - minor versions: 5 minor BC breaks allowed. - patch versions: 1 BC break allowed. Thoughts? Am I thinking too much? Is this idea unfeasible? Is it a good idea? Regards, -- Florian Margaine
